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

241–250 of 352 posts

Re: Removing XSLT for a more secure browser

#241

Post by metadope »

userbinator wrote: post #207

If they really cared about "security" they would remove JS or try to encourage minimising its use. That is a huge attack surface in comparison, but they obviously want to keep it so they can shove in more invasive and hostile user-tracking and controlling functionality.

I do all of my browsing with Javascript disabled. I've done this for decades now, as a security precaution mainly, but I've also enjoyed some welcome side-effects where paywalls disappeared and ads became static and unobtrusive. I wasn't looking for those benefits but I'll take 'em. In stride.

I've also witnessed a welcome (but slow) change in site implementations over the years: there are few sites completely broken by the absence of JS. Still some give blank screens and even braindead :hidden attributes thrown into the main page to needlessly forbid access... but not as many as back in the day when JS first became the rage.

I don't know much about XSLT other than the fact that my Hiawatha web server uses it to make my directory listings prettier, and I don't have to add CSS or JS to get some style. I hate to see a useful standard abandoned by the big boys, but what can I do about it?

I bristle when I encounter pages with a few hundred words of content surrounded by literally megabytes of framework and flotsam, but that's the gig, right, wading through the crap to find the ponies.

Re: Removing XSLT for a more secure browser

#242

Post by larusso »

mpyne wrote: post #234
kome wrote: post #180

Earlier quoted context omitted.

json is sort of a gresham's law "bad money drives out the good" but for tech: lazy and forgiving technologies drive out the better but stricter ones. bad technology seems to make life easier at the beginning, but that's why we now have sloppy websites that are an unorganized mess of different libraries, several MB in size without reason, and an absolute usability and accessibility nightmare. xhtml and xml were better…

> lazy and forgiving technologies drive out the better but stricter ones. JSON is not "lazy and forgiving" (seriously, go try adding a comment to it). It was just laser-focused on what the actual problem was that needed to be solved by many devs in day-to-day practice. Meanwhile XML wanted to be an entire ecosystem, its own XML Cinematic Universe, where you had to adopt it all to really use it. It's not surprising to…

Don’t know if I would describe it as much better. I see it similar to the whole SQL -> NOSQL -> let’s add all the feature and end up with SQL. JSON undergo a similar story with the difference that we didn’t go back to XML. What I mean is to simplify and then realize what was actually missing. But I agree for the smaller services and state transfer especially in web XML was just too damn big and verbose. But conceptually it was great.

Re: Removing XSLT for a more secure browser

#243

Post by cxr »

shadowgovt wrote: post #229
cxr wrote: post #221

Earlier quoted context omitted.

Do you still beat your wife? https://en.wikipedia.org/wiki/Do_you_still_beat_your_wife? >

I don't think that applies here (especially since I didn't even ask a question). "I'm sad it's going away in the client!" "So move it to the server, and the end-user will get essentially the same experience." Am I missing something here?

> especially since I didn't even ask a question

Oh, that's the operative part? Accept my apologies. What I meant to say is, "I can see that you're deeply, deeply concerned about being able to continue beating your wife. I think you should reconsider your position on this matter."

No question mark, see? So I should be good now.

> Am I missing something here?

Probably not. People who engage in the sort of underhandedness linked to above generally don't do it without knowing that they're doing it. They're not missing anything. It's deliberate.

So, too, I would guess, is the case with you—particularly since your current reply is now employing another familiar underhanded rhetorical move. Familiar because I already called it out within the same comment section:

> The problem is that there is content that works today that will break after the Chrome team follows through on their announced plans of shirking on their responsibility to not break the Web. That's what the problem is. Any "solution" that involves people having to go around un-breaking things that the web browser broke is not a solution to the problem that the Chrome team's actions call for people to go around un-breaking things that the web browser broke.

https://news.ycombinator.com/item?id=45824392>

Re: Removing XSLT for a more secure browser

#244

Post by dfabulich »

stickfigure wrote: post #140
dfabulich wrote: post #128

Earlier quoted context omitted.

But, that's what XSL is! XSL is a Turing-complete programming language in XML for processing XML documents. Being in XML is a big part of what makes XSL so awful to write.

XSL may be Turing-complete but it's not a programming language and wasn't intended to be one. It's a declarative way to transform XML. When used as such I never found it awful to write... it's certainly much easier than doing the equivalent in general purpose programming languages. Maybe by analogy: There are type systems that are Turing complete. People sometimes abuse them to humorous effect to write whole programs…

XSL is a functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function.

Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad.

The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements.

XSL's "escape hatch" is to allow arbitrary Turing-complete transformations. This was always intended to exist, to make easy transformations easy and hard transformations possible.

You basically never need to write Turing-complete code in a type system, but in any meaningful XSL project you will absolutely need to write Turing-complete XSL.

XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled.

Re: Removing XSLT for a more secure browser

#245

Post by aleph_minus_one »

Kwpolska wrote: post #185
robocat wrote: post #177

Earlier quoted context omitted.

Which popular browsers are significantly leaning on individual contributors or volunteers?

Google decided to drop XSLT, because the volunteer-maintained libxslt had no maintainers for some time. So, instead of helping the project, they just decided to remove a feature.

But by (attempting to) remove this dependency, Google indeed decided to stop piggy-backing on another volunteer - as requested.

Be careful what you wish for. :-)

Re: Removing XSLT for a more secure browser

#246

Post by al_be_back »

Removing html and css would also make the browser more secure - but I would argue also very counter productive for users.

Most of read-only content and lite editing can be achieved with raw data + xslt.

The web has become a sledgehammer for clacking a nut.

For example, with xslt you could easily render a read only content without complex and expensive office apps. That is enough for Academia, Gov, and small businesses.

Re: Removing XSLT for a more secure browser

#247

Post by shadowgovt »

cxr wrote: post #219
shadowgovt wrote: post #79

Earlier quoted context omitted.

> 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.

> 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." This is a (poor) attempt at gaslighting/retconning. The phrase "Don't break the Web" is not original to this thread. (I can't say I look forward to your follow-up reply employing sleights of hand like claims about how stuff like Flash that was never standardized, or the withdrawal of experiment…

Mozilla's own site expounds on "Don't Break the Web" as "Web browser vendors should be able to implement new web technologies without causing a difference in rendering or functionality that would cause their users to think a website is broken and try another browser as a result."

There is no meaningful risk of that here. The percentage of web users who are trying to understand content via XSLT'd RSS is nearly zero, and for everyone who is, there is either polyfill or server-side rendering to correct the issue.

> and those engineers can and should go work on Android and iOS

With respect: taken to its logical conclusion, that would be how the web as a client-renderable system dies and is replaced by Android and iOS apps as the primary portal to interacting with HTTP servers.

If the machine is so complex that nobody wants to maintain it, it will go unmaintained and be left behind.

Re: Removing XSLT for a more secure browser

#248

Post by shadowgovt »

cxr wrote: post #243
shadowgovt wrote: post #229

Earlier quoted context omitted.

I don't think that applies here (especially since I didn't even ask a question). "I'm sad it's going away in the client!" "So move it to the server, and the end-user will get essentially the same experience." Am I missing something here?

> especially since I didn't even ask a question Oh, that's the operative part? Accept my apologies. What I meant to say is, "I can see that you're deeply, deeply concerned about being able to continue beating your wife. I think you should reconsider your position on this matter." No question mark, see? So I should be good now. > Am I missing something here? Probably not. People who engage in the sort of underhandedne…

I seem to have personally offended you, and for that I am sorry.

This seems personal to you so I'll bow out of further discourse on the subject as it is not particularly personal to me. The websites I maintain use a framework to build RSS output, and the framework will be modified to do server-side translation or polyfill as needed to provide a proper HTML display experience for end-users who want that.

Re: Removing XSLT for a more secure browser

#249

Post by QuadrupleA »

cxr wrote: post #235
QuadrupleA wrote: post #80

Earlier quoted context omitted.

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,…

Point to the part of your comment that has any-fucking-thing to do with the topic at hand (i.e. engages with the actual substance of the comment that it's posted as a reply to). Your comment starts with "Yes but", as if it to present it as a rebuttal or rejoinder to something that was said, but then proceeds into total non-sequitur. It's an unrestrained attempt at a change of subject and makes for a not-very-hard-to-…

Alright, you're extremely rude and combative so I'll probably tap out here.

But consider if the "yellow tchotchkes" draw some power from my house, produce some stinky blue smoke that occasionally wafts over, requires a government-paid maintenance person to occasionally stop by and work on, that I partly pay for with my taxes.

That's my point.

Re: Removing XSLT for a more secure browser

#250

Post by shadowgovt »

lenkite wrote: post #112
QuadrupleA wrote: post #80

Earlier quoted context omitted.

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,…

Remove crappy JS APIs and other web-tech first before deprecating XSLT - which is a true-blue public standard. For folks who don't enable JS and XML data, XSLT is a life-saver.

But XSLT can be replicated with JavaScript and the reverse is, sadly, untrue.

So if only one needed to go, it seems obvious which it should be.

Post reply on HN