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

321–330 of 352 posts

Re: Removing XSLT for a more secure browser

#321

Post by lifthrasiir »

array_key_first wrote: post #320
lifthrasiir wrote: post #279

Earlier quoted context omitted.

While JIT exploits represent a large share of vulnerabilities in JS engines, there are enough other classes of vulnerabilities that simply turning JIT off is not sufficient. (The same goes for simply turning JS off, the Web browser internal is complex enough even without JS.)

Turning off the JIT eliminates an entire class of vulnerabilities just by nature of how the JIT works. Ironically, JIT JS is much more susceptible to buffer overflow exploits than even the C code that backs XSLT - because the C code doesn't use w+x memory pages!

Yeah, turning off the JS or Web eliminates an entire class of vulnerabilities just by nature of how the JS or Web works (running untrusted code or showing untrusted content in the local machine) as well. That's no surprise.

Re: Removing XSLT for a more secure browser

#322

Post by [deleted] »

shadowgovt wrote: post #290
cxr wrote: post #286

Earlier quoted context omitted.

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.

[deleted]

Re: Removing XSLT for a more secure browser

#323

Post by cxr »

shadowgovt wrote: post #290
cxr wrote: post #286

Earlier quoted context omitted.

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.

At the very least it's (probably*) illegal whether you agree with it or not. Even where it's not illegal, physical violence against your partner isn't okay, even if they've angered you.

* depending on jurisdiction

Re: Removing XSLT for a more secure browser

#324

Post by array_key_first »

lifthrasiir wrote: post #321
array_key_first wrote: post #320

Earlier quoted context omitted.

Turning off the JIT eliminates an entire class of vulnerabilities just by nature of how the JIT works. Ironically, JIT JS is much more susceptible to buffer overflow exploits than even the C code that backs XSLT - because the C code doesn't use w+x memory pages!

Yeah, turning off the JS or Web eliminates an entire class of vulnerabilities just by nature of how the JS or Web works (running untrusted code or showing untrusted content in the local machine) as well. That's no surprise.

I feel like you're being purposefully obtuse.

The problem with JS isn't running untrusted code. That's easy and solved, we've been doing that for decades.

The problem with the JIT is compiling instructions, writing them to memory pages, and then executing them. This means your memory MUST be w+x.

This is really, really bad. If you have any way to write to memory unsafely, you can write arbitrary code and then execute it. Not arbitrary JS code. Arbitrary instructions. In the browsers process.

Even C and C++ does not have this type of vulnerability. At best, you can overwrite the return pointer with a buffer overflow and execute some code somewhere. But it's not 1995 anymore. I can't just write shell code in the buffer and then naively jump back into the buffer.

But with JIT JS, I can.

Re: Removing XSLT for a more secure browser

#325

Post by shadowgovt »

cxr wrote: post #323
shadowgovt wrote: post #290

Earlier quoted context omitted.

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

At the very least it's (probably*) illegal whether you agree with it or not. Even where it's not illegal, physical violence against your partner isn't okay, even if they've angered you. * depending on jurisdiction

This is all entirely off-topic from using XSLT in a website. As opposed to rendering XSLT client-side or server side, or rendering it using an in-engine native-implementation API or a JavaScript engine.

Happy to talk about those if you want; not interested at all in this violence digression you've decided to go on.

Re: Removing XSLT for a more secure browser

#326

Post by shadowgovt »

righthand wrote: post #310
shadowgovt wrote: post #305

Earlier quoted context omitted.

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

> Which probably has 10x the complexity and 10x security plane

... and 10x the utility, since unlike XSLT Bluetooth requires sandboxed and mediated access to OS-level APIs that cannot be feature-compatible replicated with 3MB of JavaScript.

Re: Removing XSLT for a more secure browser

#327

Post by shadowgovt »

dpark wrote: post #318
shadowgovt wrote: post #293

Earlier quoted context omitted.

Gopher support in browser was never, IIUC, a w3c standard. Piecing the puzzle pieces together from multiple threads: There's an argument to be made that the HTML standard, which post-dates the browser wars and was more-or-less the detente that was agreed upon by the major vendors of the day, includes a rule that no compliant browser should drop a feature (no matter how old or unused that feature is) because "Don't br…

> that there's a good chance this drop will de-facto kill XSLT client-side rendering as a technology web devs can rely upon regardless of what the spec says. This is coming out of WHATWG so in actuality the spec itself is being updated to remove the functionality. So yes, the end state is very much that devs cannot rely on this functionality.

Do you have a link to the WHATWG discussion? I went looking for it yesterday and was unable to find details.

Re: Removing XSLT for a more secure browser

#328

Post by dpark »

shadowgovt wrote: post #327
dpark wrote: post #318

Earlier quoted context omitted.

> that there's a good chance this drop will de-facto kill XSLT client-side rendering as a technology web devs can rely upon regardless of what the spec says. This is coming out of WHATWG so in actuality the spec itself is being updated to remove the functionality. So yes, the end state is very much that devs cannot rely on this functionality.

Do you have a link to the WHATWG discussion? I went looking for it yesterday and was unable to find details.

https://github.com/whatwg/html/issues/11523

From there they link to the minutes for the meeting where this was raised. Interestingly the Google engineer who raised this at the meeting was formerly at Mozilla for years. I don’t know if Mozilla was already looking to remove this or not.

Re: Removing XSLT for a more secure browser

#329

Post by righthand »

shadowgovt wrote: post #313
righthand wrote: post #308

Earlier quoted context omitted.

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

I don't see how it can be reasonably asserted that this is "destruction of XSLT in the browser" when there are multiple XSLT conversion engines available in JavaScript.

Because when you convert xslt to javascript it’s not xslt is it? It’s javascript pretending to xslt. Furthermore if you restrict rendering xslt to javascript then you lose all the performance benefits of xslt at the engine level.

Also if I’m going to be using Javascript why would I then reach for xslt instead of the other 8000 templating libraries.

All your “its fine to remove it” arguments only work if you ignore all the reasons it’s not fine to remove it. That’s awfully convenient.

Re: Removing XSLT for a more secure browser

#330

Post by righthand »

shadowgovt wrote: post #315
righthand wrote: post #309

Earlier quoted context omitted.

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

These are all great ideas and I support you pursuing what you are passionate about.

No you don’t because my passions are for a open technically varied unbroken web and you’ve spent the entire time trying to paint me as crazy for wanting any of that just because not all technology is equally popular or profitable for Google.
Post reply on HN