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

301–310 of 352 posts

Re: Removing XSLT for a more secure browser

#301

Post by righthand »

shadowgovt wrote: post #294
righthand wrote: post #291

Earlier quoted context omitted.

Yes I mourn the loss of Gopher, RSS, XML, etc. Browser developers don’t have to do shit but it’s against the idea of an open web to kill off technology, especially one that’s A PART OF THE HTML STANDARD. You love a closed web. That’s why you’re backing Google and arguing for this. I can’t change that there are so many weak minded “yes daddy Google” people in the world. All I can do is advocate we support many technol…

Practically speaking, what does "open web" vs. "Closed web" mean in this context? Is "open web" just "maximally complies with the w3c standard?"

Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use.

Not: popular browsers needle through technologies and tell everyone they know best

Does that make sense? Openess on the web isn’t a new term or concept so I’m not sure what’s confusing. It’s certainly not killing off technologies people are using.

What is open web to you? “Overpaid Mba at Google says this is best so you better fall in line.”

Re: Removing XSLT for a more secure browser

#303

Post by righthand »

tptacek wrote: post #297
righthand wrote: post #295

Earlier quoted context omitted.

Ah you’re just a Google boot licker. Sorry I wasted my time responding, I thought you were serious.

I'm not a Google boot licker, I just hate XSLT, like (empirically) most developers.

Well maybe you should at least start licking some boots because your attitude towards a templating language is the billion dollar corpo way. You fit right in and could at least get some perks out shitting on technology you probably never fully understood and you get to be a better contributor to helping close off the web.

All of the disliked technologies and people who use them will be gone one day as we champion these destructive initiatives onward. Thank you hater!

Re: Removing XSLT for a more secure browser

#304

Post by shadowgovt »

righthand wrote: post #300
dpark wrote: post #296

Earlier quoted context omitted.

The proposal is to remove support and change the standard . Standards evolve. Sometimes features are removed because they are costly to maintain or security problems or both. The fact is that all the major browsers are looking to deprecate this functionality because they all agree it’s a security bug farm and too underutilized to justify fixing. > You love a closed web. That’s why you’re backing Google and arguing fo…

> Sometimes features are removed because they are costly to maintain or security problems or both. But the features and tech doesn’t have security problems. The library implementation does. This is exactly the kind of bad faith argument I’m talking about. Please just for one second try making an argument pro-XSLT and then try to compare the two mind sets about technology here. There is no negative trade off by mainta…

There's a lot of people saying "All we need to do is maintain libxslt" and a distinct lack of people actually stepping up to maintain libxslt.

I, for one, won't. Not for the purpose of keeping it in the browser. There are just too many other ways to do what it does for me to want that (and that's before we get into conversations about whether I want to be working with XML in the first place on the input side).

> not being lazy developers

Laziness is one of the three great virtues of programming. Every second not spent maintaining libxslt is a second we can spend on something more people care about.

It's a rule for writers, but it applies to software architecture also: kill your darlings.

Re: Removing XSLT for a more secure browser

#305

Post by shadowgovt »

righthand wrote: post #301
shadowgovt wrote: post #294

Earlier quoted context omitted.

Practically speaking, what does "open web" vs. "Closed web" mean in this context? Is "open web" just "maximally complies with the w3c standard?"

Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use. Not: popular browsers needle through technologies and tell everyone they know best Does that make sense? Openess on the web isn’t a new term or concept so I’m not sure what’s confusing. It’s certainly not killing off technologies people are using. What is open web to you? “Overpaid Mba at Google says…

Given that the thing we want to support can be supported via server-side translation, client-side translation in JavaScript, or automatic detection and translation via a third-party plugin in JavaScript... What bearing on the open web does it have to preserve this functionality as a JavaScript-accessible API built into the browser?

I don't see how removing this API harms the open web. I do see how it imposes some nonzero cost on website maintainers to adapt to the removal of the API, and I respect that cost is nonzero.

... but I also watched OpenGL evolve into OpenGL ES and the end result was a far better API than we started with.

I don't think XSLTProcessor joining document.defaultCharset in the history books is damage to the open web.

ETA: And not that it matters over-much, but the "overpaid Mba" is an electrical engineering Ph.D who came to software via sensor manufacturing, so if you're going to attempt to insult someone's training, maybe get it right? Not that he'd be wrong if he were an Mba either, mind.

Re: Removing XSLT for a more secure browser

#306

Post by dpark »

righthand wrote: post #300
dpark wrote: post #296

Earlier quoted context omitted.

The proposal is to remove support and change the standard . Standards evolve. Sometimes features are removed because they are costly to maintain or security problems or both. The fact is that all the major browsers are looking to deprecate this functionality because they all agree it’s a security bug farm and too underutilized to justify fixing. > You love a closed web. That’s why you’re backing Google and arguing fo…

> Sometimes features are removed because they are costly to maintain or security problems or both. But the features and tech doesn’t have security problems. The library implementation does. This is exactly the kind of bad faith argument I’m talking about. Please just for one second try making an argument pro-XSLT and then try to compare the two mind sets about technology here. There is no negative trade off by mainta…

> There is no negative trade off by maintaining XSLT other than not being lazy developers.

Only because it’s not your money or time being traded. Yes, if we pretend that engineering effort is free then there’s no reason Google couldn’t just rewrite this entire library in Rust or whatever. But if that were true you would just rewrite the library yourself and send the pull request to Chromium.

In the real world where engineering costs time and money, every decision is a trade off. Someone rewriting libxslt to be secure is someone who’s not implementing other features and who’s not fixing other bugs on the backlog.

Resources allocated to Chromium are finite and while sure, Google could hire 2 more engineers to do this, in reality those 2 new engineers could and would be assigned to higher priority work.

> this is a Google engineer doing things because it’s easier, not “right” or “the difficult choice”.

You keep blaming Google specifically. All of the major browsers are planning to drop this though. They all agree this is the right trade off.

Re: Removing XSLT for a more secure browser

#307

Post by dpark »

righthand wrote: post #301
shadowgovt wrote: post #294

Earlier quoted context omitted.

Practically speaking, what does "open web" vs. "Closed web" mean in this context? Is "open web" just "maximally complies with the w3c standard?"

Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use. Not: popular browsers needle through technologies and tell everyone they know best Does that make sense? Openess on the web isn’t a new term or concept so I’m not sure what’s confusing. It’s certainly not killing off technologies people are using. What is open web to you? “Overpaid Mba at Google says…

> Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use.

The “wide range of technologies” is not what makes the web “open”.

The openness comes from the fact that anyone can write web sites and anyone can write a browser that can render the same websites that chrome can render. “More features” does not imply “more open”.

Dropping support for xslt would make the web less open if it were being replaced by some proprietary Google tech. But that’s not what’s happening here at all.

> Not: popular browsers needle through technologies and tell everyone they know best

How else would it possibly work? Everyone has to actively choose the features they will build and support.

Re: Removing XSLT for a more secure browser

#308

Post by righthand »

dpark wrote: post #306
righthand wrote: post #300

Earlier quoted context omitted.

> Sometimes features are removed because they are costly to maintain or security problems or both. But the features and tech doesn’t have security problems. The library implementation does. This is exactly the kind of bad faith argument I’m talking about. Please just for one second try making an argument pro-XSLT and then try to compare the two mind sets about technology here. There is no negative trade off by mainta…

> There is no negative trade off by maintaining XSLT other than not being lazy developers. Only because it’s not your money or time being traded. Yes, if we pretend that engineering effort is free then there’s no reason Google couldn’t just rewrite this entire library in Rust or whatever. But if that were true you would just rewrite the library yourself and send the pull request to Chromium. In the real world where e…

Surprise, there’s already an effort to write xml related libraries in Rust: xrust library for one.

It doesn’t have to be this pearl gripping bitching and moaning about budgets and practicality. That’s just what Google wants you to believe.

No all of the major browsers weren’t planning to drop this. It literally only started happening because of Google. And Google is essentially forcing the hand. Again this is bad faith argument. I will not concede on my thoughts on this unnecessary destruction of XSLT in the browser while other technologies get a pass.

Re: Removing XSLT for a more secure browser

#309

Post by righthand »

shadowgovt wrote: post #304
righthand wrote: post #300

Earlier quoted context omitted.

> Sometimes features are removed because they are costly to maintain or security problems or both. But the features and tech doesn’t have security problems. The library implementation does. This is exactly the kind of bad faith argument I’m talking about. Please just for one second try making an argument pro-XSLT and then try to compare the two mind sets about technology here. There is no negative trade off by mainta…

There's a lot of people saying "All we need to do is maintain libxslt" and a distinct lack of people actually stepping up to maintain libxslt. I, for one, won't. Not for the purpose of keeping it in the browser. There are just too many other ways to do what it does for me to want that (and that's before we get into conversations about whether I want to be working with XML in the first place on the input side). > not…

Sure. But since this announcement I’ve been planning ways to support xslt. Here are the projects I’m considering:

- iced-ui browser with xslt + servo

- contribute to xslt xrust project

- investigate sandboxing xslt in firefox and implementing xrust

- same as the previous but for Chrome

- have an llm generate 1000s of static websites built in xslt and deploy them across the internet

- promote and contribute to the recent Show HN post of an xslt framework

I figure if I can generate enough effort to spam the web with xslt sites then they can’t remove it. Ultimately the first goal is to delay the removal from Chrome. This will delay the removal in other browsers. I don’t care if it’s ineffective. It’s better than doing nothing.

So you can take your lazy tenants of software engineering and your “hyuck Google knows best” eslewhere.

Re: Removing XSLT for a more secure browser

#310

Post by righthand »

shadowgovt wrote: post #305
righthand wrote: post #301

Earlier quoted context omitted.

Open web means popular browsers supporting a wide range of technologies that institutions, businesses, and people use. Not: popular browsers needle through technologies and tell everyone they know best Does that make sense? Openess on the web isn’t a new term or concept so I’m not sure what’s confusing. It’s certainly not killing off technologies people are using. What is open web to you? “Overpaid Mba at Google says…

Given that the thing we want to support can be supported via server-side translation, client-side translation in JavaScript, or automatic detection and translation via a third-party plugin in JavaScript... What bearing on the open web does it have to preserve this functionality as a JavaScript-accessible API built into the browser? I don't see how removing this API harms the open web. I do see how it imposes some non…

No the Mba is Freeds boss who installed him there and ensure he enforces closing of the web. Coming from sensor manufacturing to software isn’t really that impressive but it does make sense why a sensor manufacturing engineer would make arguments for removing a spec like XSLT but not a terribly complicated and security vulnerable spec like bluetooth. Which probably has 10x the complexity and 10x security plane of xslt. Thank you this whole thing is an even bigger joke.

Enjoy the precedent this sets for other tech not in the Google stable. You clearly are getting what you want so why continue this discussion. Who are you trying to convince?

Post reply on HN