troupo (u/troupo) - Readit News

troupo commented on Europe's crusade against air conditioning is insane noahpinion.blog/p/europes... · Posted by u/paulpauper

troupo · 2 days ago

To add to this:

- we should also mandate external window shutters on all buildings so that the sun heats that and not the apartment/house

- we should also mandate that parking lots are always covered with trees, especially when they are close to buildings. Look at this bullshit: https://x.com/dmitriid/status/1955506095239336137

Edit: as someone else mentioned. Also: thicker walls.

And only after all this is implemented can we start a discussion of whether AC is needed. Yes, right now it's a necessity across most of Europe

troupo commented on Show HN: JavaScript-free (X)HTML Includes github.com/Evidlo/xsl-web... · Posted by u/Evidlo

afavour · 2 days ago

> The GP asked for a citation for XSLT support going behind a flag in the next version of Chrome

> Add flag to disable XSLT

Two very different things. OP is talking about XSLT support going behind a flag, you’re citing XSLT deprecation going behind a flag. The default state matters (and the default state is undeprecated)

It makes sense that the Chrome team would do what they’re doing, otherwise it’s very difficult for anyone to assess the impact of XSLT deprecation.

troupo · 2 days ago

> OP is talking about XSLT support going behind a flag, you’re citing XSLT deprecation going behind a flag.

Literally from my link:

--- start quote ---

Add a feature flag to disable XSLT

This adds a feature flag that disables:

- XSLTProcessor

- XSLT Processing Instructions

--- end quote ---

troupo commented on XSLT removal will break multiple government and regulatory sites github.com/whatwg/html/is... · Posted by u/colejohnson66

JimDabell · 2 days ago

> Indeed. And now Google cites lack of resources, complexity, a large attack surface, and small percentage of page views, and barrels forward with removing XSLT. Without a single lengthy discussion.

You’re equivocating here.

You were complaining that browser maintainers had no qualms about adding functionality with large attack surfaces. This was untrue and I pointed out that these things have received a lot of attention from browser maintainers.

You’re now presenting removing XSLT not having received due discussion as if it were the same thing. It’s not.

Adding a feature with a large attack surface area is a security risk that needs to be evaluated.

Removing a feature with a large attack surface area is not a security risk – it’s the opposite!

The reason people want to have a lengthy discussion when adding features is to avoid introducing security issues.

The reason you want to have a lengthy discussion when removing XSLT is because you want the XSLT functionality.

These two situations are not the same thing at all but you are presenting them as equivalent.

Furthermore, the security risks of XSLT have already been clearly shown:

> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.

— https://www.offensivecon.org/speakers/2025/ivan-fratric.html

— https://www.youtube.com/watch?v=U1kc7fcF5Ao

If you were honestly worried about “the huge attack surface areas” of these features, then you should be glad that they had lengthy discussions beforehand, and you should be worried about XSLT being present in browsers. But instead you are using the discussion of those new features as a way to defend XSLT being present.

> Yo, if a feature is deliberately ignored, let's remove it. That's exactly what hairless to SVG for example. Oh wait...

This makes no sense, SVG is in widespread use.

> On top of that XSLT is used on more web sites than, say, WebSerial

I already explained why it makes no sense to make this comparison.

troupo · 2 days ago

> You’re now presenting removing XSLT not having received due discussion as if it were the same thing. It’s not.

It is.

Large complex spec with a potentially large attack service, but which is still in use (even though small use, but not enough to justify removal according to very same browser vendors who are not Google, and according to Google's own document)?

> then you should be glad that they had lengthy discussions beforehand

I'm not glad, because Google shipped them regardless of any concerns from any of the other browser vendors.

Oh, they also shipped large currently unused specs without even providing a spec for other browsers to look at (looking at WebTransport). Imagine if that had any CVE entries https://nvd.nist.gov/vuln/detail/CVE-2024-7255 https://nvd.nist.gov/vuln/detail/CVE-2025-1931

> This makes no sense, SVG is in widespread use.

SVG was also sort of languishing in v1 with no interest to update it and make it more usable. But then SVG 2 happened.

troupo commented on Show HN: JavaScript-free (X)HTML Includes github.com/Evidlo/xsl-web... · Posted by u/Evidlo

magicalist · 2 days ago

> But they did anyway.

Did what? The GP asked for a citation for XSLT support going behind a flag in the next version of Chrome, but you forgot to add that. As best as I can tell, the GP is right and you're confused.

troupo · 2 days ago

Tracking issue: https://issues.chromium.org/issues/435623334

Add flag to disable XSLT: https://chromium-review.googlesource.com/c/chromium/src/+/68...

It's approved, I don't know which release it will be.

Additionally, quote from the GitHub discussion:

--- start quote ---

Q: why has Chrome already started working on removing the feature from the browser?

A: To explore the effects of removal. It's hard to tell what will break without being able to turn it off and see.

https://github.com/whatwg/html/issues/11582#issuecomment-320...

--- end quote ---

troupo commented on What about using rel="share-url" to expose sharing intents? shkspr.mobi/blog/2025/08/... · Posted by u/edent

jeroenhd · 2 days ago

But unlike the proposal by the blog author, it's already been implemented by at least one browser vendor and received positive responses from another.

Sure, we could throw in another spec and maybe Mozilla will implement this one and maybe Safari won't be neutral to the new one, but why go through that effort when there's already a working solution to this problem?

troupo · 2 days ago

I've responded to a similar question in a sibling comment: https://news.ycombinator.com/item?id=44989500

troupo commented on XSLT removal will break multiple government and regulatory sites github.com/whatwg/html/is... · Posted by u/colejohnson66

JimDabell · 2 days ago

> > Simple: xslt is a giant attack surface entirely in C, and no browser maintainer cares to expend resources on maintaining that

> And yet they have no qualms shoving huge attack surfaces in the form of WebUSB, WebSerial, WebMIDI, WebTransport, WebBluetooth

This is not true. Both Mozilla and Apple rejected WebUSB, WebSerial, and WebBluetooth, and Apple rejected WebMIDI as well. Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand. So yes, browser maintainers definitely do have qualms about shoving those huge attack surfaces in there, and those qualms are a matter of public record you can read at your leisure.

> most of which have as much usage as XSLT

It doesn’t make sense to compare the usage of proposed features to a feature that has been implemented by all browsers for 25 years. Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.

troupo · 2 days ago

> Your list is mostly Blink-only APIs that Google have failed to convince other rendering engines to implement. And they all had lengthy discussions about security beforehand.

Indeed. And now Google cites lack of resources, complexity, a large attack surface, and small percentage of page views, and barrels forward with removing XSLT. Without a single lengthy discussion.

> Being available for 25 years and going almost entirely unused is a very strong signal that XSLT is not worth keeping around.

Yes, if a feature is deliberately ignored, let's remove it. That's exactly what happened to SVG for example. Oh wait...

On top of that XSLT is used on more web sites than, say, WebSerial which managed to climb to a whooping 0.000596% this year https://chromestatus.com/metrics/feature/timeline/popularity...

To quote Chrome's own document:

--- start quote ---

As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in 10 million) is generally considered trivial. There are around 771 billion web pages viewed in Chrome every month (not counting other Chromium-based browsers). So seriously breaking even 0.0001% still results in someone being frustrated every 3 seconds, and so not to be taken lightly!

https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS...

--- end quote ---

troupo commented on XSLT removal will break multiple government and regulatory sites github.com/whatwg/html/is... · Posted by u/colejohnson66

kstrauser · 2 days ago

I don’t think I’ve ever wanted to read an RSS feed directly, although I subscribe to a lot of them. Is that a popular reading method?

troupo · 2 days ago

It's a popular presentation format for RSS feeds. And you don't need to somehow attach a Javascript polyfill to an XML feed to make it readable for humans

troupo commented on XSLT removal will break multiple government and regulatory sites github.com/whatwg/html/is... · Posted by u/colejohnson66

vitus · 2 days ago

nit: document.applets is not the same as the <applet> tag.

    Note: Support for the <applet> element has been removed by all browsers. Therefore, calling document.applets always returns an empty collection.

https://developer.mozilla.org/en-US/docs/Web/API/Document/ap...

For instance: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...

    The <applet> element has been removed (Firefox bug 1279218).

Also see https://github.com/mdn/content/pull/26850 which removed MDN docs for the element a couple years back, citing removals from major browsers.

<font> and <frameset> are still implemented in browsers, though, even if they are fully deprecated and marked by WHATWG as obsolete and non-conforming: https://html.spec.whatwg.org/multipage/obsolete.html#non-con...

troupo · 2 days ago

Thank you for the correction!

troupo commented on XSLT removal will break multiple government and regulatory sites github.com/whatwg/html/is... · Posted by u/colejohnson66

bazoom42 · 3 days ago

WHATWG have removed features before, e.g. frameset, font, and applet elements from HTML. All of them were rarely used and had better alternatives available.

troupo · 2 days ago

> WHATWG have removed features before, e.g. frameset, font, and applet elements from HTML.

font: supported in all browsers https://caniuse.com/?search=font

frameset: supported in all browsers https://caniuse.com/?search=frameset

applet: supported in all browsers https://caniuse.com/?search=applet

> All of them were rarely used and had better alternatives available.

"Rarely used" is not enough of a justification

troupo commented on XSLT removal will break multiple government and regulatory sites github.com/whatwg/html/is... · Posted by u/colejohnson66

paulvnickerson · 3 days ago

They should switch, then. This notion that we can't peal away browser spec complexity because it will break some websites is the same reason ActiveX continued to wreck havoc long after it should have. I found multiple security vulnerabilities in XSLT back in my pen-testing days, and even if it didn't increase the threat surface, browser spec needs to be simplified anyway.

troupo · 2 days ago

> This notion that we can't peal away browser spec complexity

They are not peeling away browser complexity. They revel in browser complexity. They gleefuly make browser as complex as possible.... as long as their promotions depend on it: https://news.ycombinator.com/item?id=44989576