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

281–290 of 352 posts

Re: Removing XSLT for a more secure browser

#281

Post by JetSpiegel »

bawolff wrote: post #259
jeroenhd wrote: post #253

Earlier quoted context omitted.

The vulnerabilities themselves often didn't really affect Chrome, but by the maintainers' own admission the code was never intended to be security critical. They got burned out after a series of vulnerability reports with publication deadlines made them decide to just take security bugs like normal bugs so the community could help fix things. That doesn't really fit with the "protect users by keeping security issues…

> the maintainers' own admission the code was never intended to be security critical I find this hard to believe. XML is a portable data serialization format. The entire point of XML is to transfer data between separate parties who preumably dont trust each other. Most non browser xml usages are security criical and have been from the beginning. Just look at their website from 2001 https://web.archive.org/web/2001020…

What are you talking about, "free labor"? They are using the damn library, Google would benefit directly.

Re: Removing XSLT for a more secure browser

#282

Post by chrismorgan »

Fileformat wrote: post #168
jerf wrote: post #84

Earlier quoted context omitted.

I've been involved in the RSS world since the beginning and I've never clicked on an RSS link and expected it to be rendered in a "nice" way, nor have I seen one. "XSLT is currently the only way to make feeds into something that can still be viewed." You could use content negotiation just fine. I just hit my personal rss.xml file, and the browser sent this as the Accept header: text/html,application/xhtml+xml,applica…

Another point: it is shocking how many feeds have errors in them. I analyzed the feeds of some of the top contributors on HN, and almost all had something wrong with them. Even RSS wizards would benefit from looking at a human-readable version instead of raw XML. I ended up writing a feed analyzer that you can try on your feed: https://www.rss.style/feed-analyzer.html

> I analyzed the feeds of some of the top contributors on HN, and almost all had something wrong with them.

I’m sceptical about your analysis, because your tool makes spurious complaints about my feed https://chrismorgan.info/feed.xml> which show that it’s not parsing XML correctly. For stupid reasons¹ that I decided not to fix or work around, many of the slashes are encoded as /, which is perfectly valid, but your tool fails to decode the character references inside attribute values. I don’t know what dodgy parser you’re using, it’s possible this is the only thing it gets wrong about parsing XML², but it doesn’t instil confidence. I would expect a strict XML parser to be more reliable. I’ve literally only once encountered a feed that was invalid XML³. Liberal parsing is not a virtue, it’s fragile in a different way. Postel was wrong.

—⁂—

¹ I wish OWASP’s XSS protection cheat sheet had never been written. I will say no more.

² Honestly, parsing XML isn’t very hard; once you’re past the prologue, there are literally only about seven simple concepts to deal with (element, attribute, text, processing instructions, comments, cdata, character/entity references), with straightforward interactions. Not decoding references in attribute values is a mind-boggling oversight to me.

³ WordPress thinks it’s okay to encode U+0003 as  in an XML 1.0 document.

Re: Removing XSLT for a more secure browser

#283

Post by Fileformat »

its-summertime wrote: post #275
Fileformat wrote: post #164

Earlier quoted context omitted.

You are probably right, but it is depressing how techies don't see the big picture & don't want to provide an on-ramp to the RSS/Atom world for newcomers.

How does displaying XML using a client-side transform provide a better on-ramp compared to displaying XML using a server-side transform?

1. Everyone who uses a static site generator can add XSLT

2. Everyone who doesn't use a static site generate only has to add the XSLT file and add a single line to the XML. No need to write any code: new code is not a big deal for many HN readers, but not every blog author is a coder.

Re: Removing XSLT for a more secure browser

#284

Post by mycall »

Genbox wrote: post #163
nwellnhof wrote: post #48

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

It is also kinda a self-burn. Chromium an aging code base [1]. It is written in a memory unsafe language (C++), calls hundreds of outdated & vulnerable libraries [2] and has hundreds of high severity vulnerabilities [3]. People in glass houses shouldn't throw stones. [1] https://github.com/chromium/chromium/commits/main/?after=c5a... [2] https://github.com/chromium/chromium/blob/main/DEPS [3] https://www.cvedetails.c…

Given Google's resources, I'm a little surprised they having created an LLM that would rewrite Chromium into Go/Rust and replace all the stale libraries.

Re: Removing XSLT for a more secure browser

#286

Post by cxr »

shadowgovt wrote: post #264
cxr wrote: post #262

Earlier quoted context omitted.

Do you still beat your wife?

Don't understand the question, but I do wish you well in your future endeavors!

It's a question about whether you still beat your wife. If the answer is yes, then your answer is yes, and if the answer is no, then your answer is no.

It sounds like you're looking for a jurisdiction where you can beat your wife.

Re: Removing XSLT for a more secure browser

#287

Post by righthand »

shadowgovt wrote: post #220
righthand wrote: post #216

Earlier quoted context omitted.

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

Yes we would because people still use fax machines.

I don’t understand this “everything must be a business metric because it can, therefor if I can whittle any feature as a small minority, I am forever correct and just in destroying said technology. Look at smart and savvy I am.”

Totally brain dead.

Re: Removing XSLT for a more secure browser

#288

Post by dpark »

righthand wrote: post #287
shadowgovt wrote: post #220

Earlier quoted context omitted.

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

Yes we would because people still use fax machines. I don’t understand this “everything must be a business metric because it can, therefor if I can whittle any feature as a small minority, I am forever correct and just in destroying said technology. Look at smart and savvy I am.” Totally brain dead.

Are browser manufacturers required to support features forever no matter how low the usage is? Do you still mourn for the loss of Gopher support?

Re: Removing XSLT for a more secure browser

#289

Post by davisr »

imtringued wrote: post #277
davisr wrote: post #154

Earlier quoted context omitted.

Yeah... or...... maybe they should just build websites the proper way the first time around, returning plain HTML, perhaps with some JS extras. Any user-entered input needs to be validated again on the backend anyway, so client-side JS is often a waste.

This falls apart the moment you need to add rows to a table or show and hide things in response to values selected in a dropdown. Even the lightest JS app centered around a big form is going to become a huge pain in the ass for literally no benefit. In a company of 100 people, that <0.5% of people who disable JS could literally be one guy, or no one at all.

You can use CSS for interactive-esque things like that. Use JS for all I care, just don't make it mandatory. You /could/ refresh the page with new values. You /could/ paginate your flow. You won't, because you'd rather spend 50 hours getting your JS to work right, than 5 hours writing some PHP.

Pity.

Re: Removing XSLT for a more secure browser

#290

Post by shadowgovt »

cxr wrote: post #286
shadowgovt wrote: post #264

Earlier quoted context omitted.

Don't understand the question, but I do wish you well in your future endeavors!

It's a question about whether you still beat your wife. If the answer is yes, then your answer is yes, and if the answer is no, then your answer is no. It sounds like you're looking for a jurisdiction where you can beat your wife.

I really don't follow how wife-beating has anything to do with browser protocols or standards adoption / modification, sorry.
Post reply on HN