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

211–220 of 352 posts

Re: Removing XSLT for a more secure browser

#211

Post by righthand »

JimDabell wrote: post #68
righthand wrote: post #31

Earlier quoted context omitted.

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/moz…

So you’re choosing to help them spin the lie by cherry picking comments.

The Mozilla comment itself ends with:

> If it turns out that it's not possible to remove support, then we think browsers should make an effort to improve the fundamental security properties of XSLT even at the cost of performance.

> If it turns out not to be possible to remove the feature, we’d like to replace our current implementation. The main requirements would be compatibility with existing web content, addressing memory safety security issues, and not regressing performance on non-XSLT content. We’ve seen some interest in sandboxing libxslt, and if something with that shape satisfied our normal production requirements we would ship it.

But the only way it’s possible to remove the feature is if you ignore everyone asking you to please not to remove it.

Therefor by totally ignoring push back you can then twist Mozilla reps words to mean the only option is to remove it.

Similarly with the Webkit comment:

> WebKit is cautiously supportive.

Both these orgs requested investigation not removal. Both expressed some concern and caution. Google did not, they only ever pushed forward with removing it. Even goong so far as to ignore the followup request to implement XSLT 3.0.

No it’s not blatantly untrue. It’s unblatantly misleading.

Furthermore I’d say for those specific comments, “go ahead and remove it”, the inverse is blatantly untrue.

Re: Removing XSLT for a more secure browser

#212

Post by righthand »

rvz wrote: post #49
righthand wrote: post #2

Destroying the open web instead of advocating to fix one of the better underutilized browser technologies for a more Profitable Google. I will not forget the name Mason Freed, destroyer of open collaborative technology.

> Destroying the open web instead of advocating to fix one of the better underutilized browser technologies for a more Profitable Google. Google, Mozilla and Apple do not care if it doesn't make them money, unless you want to pay them billions to keep that feature? > I will not forget the name Mason Freed, destroyer of open collaborative technology. This is quite petty.

So is blatantly ignoring pushback against removing a feature like this. Eye for an eye.

Re: Removing XSLT for a more secure browser

#213

Post by righthand »

tptacek wrote: post #111
simoncion wrote: post #105

Earlier quoted context omitted.

You appear to have forgotten how to scroll up and notice that the name of the OP is not my name. ;)

No, I know, I'm just being silly. Sorry, I didn't mean to attribute that sentiment to you.

Hilarious, thanks. Sorry you have issues with memory.

Re: Removing XSLT for a more secure browser

#214

Post by thesuitonym »

Fileformat wrote: post #56

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

I never realized styling RSS feeds was an options. Now looking at some of the examples, I wonder how many times I've clicked on "Feed", then rolled my eyes and closed it because I thought it wasn't RSS. More than zero, I'm sure.

Re: Removing XSLT for a more secure browser

#215

Post by [deleted] »

lunar_mycroft wrote: post #142
kccqzy wrote: post #133

Earlier quoted context omitted.

Because they don't want to use the code. They begrudgingly use it to support XSLT and now they don't use it.

Maintaining web standards without breaking backwards compatibility is literally what they signed up for when they decided to make a browser. If they didn't want to do that job, they shouldn't have made one.

[deleted]

Re: Removing XSLT for a more secure browser

#216

Post by righthand »

shadowgovt wrote: post #78
righthand wrote: post #50

Earlier quoted context omitted.

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.

Yes excellent way to continue to diminish users of tech you don’t agree with.

“The people who actually use it are wrong and don’t matter!”

Re: Removing XSLT for a more secure browser

#217

Post by behringer »

Fileformat wrote: post #56

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

It's the right direction if you're google. This is why Google should not be allowed to control the web. Support firefox, dump google.

Re: Removing XSLT for a more secure browser

#218

Post by zzo38computer »

davisr wrote: post #87
Aurornis wrote: post #77

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

In addition to those things, JavaScripts can also cause some things to not work properly even though they would work without JavaScripts.

Re: Removing XSLT for a more secure browser

#219

Post by cxr »

shadowgovt wrote: post #79
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.

> 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 experimental APIs that weren't both stable/finalized and implemented by all the major browsers, or the long tail of stuff on developer.mozilla.org that is marked "deprecated" (but nonetheless still manages to work) are evidence of your claim and that browser makers really do have a history of doing this sort of thing. This is in fact the first time something like this has actually happened—all because there are engineers working on browsers at Google (and Mozilla and Apple) that are either confused about how the Web differs from, say, Android and iOS, or resentful of their colleagues who get to work on vendor SDKs where the API surface area is routinely rev'd to remove whatever they've decided no longer aligns with their vision for their platform. That's not what the Web is, and those engineers can and should go work on Android and iOS instead of sabotaging the far more important project of attending to the only successful attempt at a vendor-neutral, ubiquitous, highly accessible, substrate for information access that no one owns and that doesn't fuck over the people who rely on it being stable.)

Re: Removing XSLT for a more secure browser

#220

Post by shadowgovt »

righthand wrote: post #216
shadowgovt wrote: post #78

Earlier quoted context omitted.

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.

Yes excellent way to continue to diminish users of tech you don’t agree with. “The people who actually use it are wrong and don’t matter!”

I'm not personally in the business of maintaining a browser.

But if I were, and I were looking to decrease cost of maintenance, "This entire rendering framework that supports a 0.02% use case" would be an outlier for chopping-block consideration. Not all corner-case features match that combination of cost-to-maintain and adoption (after, what, decades at this point?).

We wouldn't be arguing the point if the feature in question were fax machine support, right?

Post reply on HN