Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

hacks.mozilla.org

Post reply on HN
Print view View original

31–40 of 172 posts

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#31

Post by thunderfork »

Vinnl wrote: post #20
post-it wrote: post #13

Earlier quoted context omitted.

> you would eliminate all usage of innerHTML The mythical refactor where all deprecated code is replaced with modern code. I'm not sure it has ever happened. I don't have an alternative of course, adding new methods while keeping the old ones is the only way to edit an append-only standard like the web.

I kinda like the way JS evolved into a modern language, where essentially ~everyone uses a linter that e.g. prevents the use of `var`. Sure, it's technically still in the language, but it's almost never used anymore. (Assuming transpilers have stopped outputting it, which I'm not confident about.)

Depending on the transpiler and mode of operation, `var` is sometimes emitted.

For example, esbuild will emit var when targeting ESM, for performance and minification reasons. Because ESM has its own inherent scope barrier, this is fine, but it won't apply the same optimizations when targeting (e.g.) IIFE, because it's not fine in that context.

https://github.com/evanw/esbuild/issues/1301

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#32

Post by Aachen »

josefx wrote: post #19
noduerme wrote: post #18

Earlier quoted context omitted.

Finally, a good use case for AI.

Wouldn't AI be trained on data using innerHTML?

My experience is that they somehow print quite modern code despite things like ES6 being too new to be standard knowledge even for me and I'm not even middle-aged yet

Maybe the last 10 years saw so much more modern code than the last cumulative 40+ years of coding and so modern code is statistically more likely to be output? Or maybe they assign higher weights to more recent commits/sources during training? Not sure but it seems to be good at picking this up. And you can always feed the info into its context window until then

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#33

Post by charcircuit »

Aachen wrote: post #30
noduerme wrote: post #18

Earlier quoted context omitted.

Finally, a good use case for AI.

Yeah, using a kilowatt GPU for string replacement is going to be the killer feature. I probably shouldn't even be joking, people are using it like this already

When the condition for when you want to replace is hard to properly specify, AI shines for such find and replaces.

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#34

Post by delaminator »

Vinnl wrote: post #20
post-it wrote: post #13

Earlier quoted context omitted.

> you would eliminate all usage of innerHTML The mythical refactor where all deprecated code is replaced with modern code. I'm not sure it has ever happened. I don't have an alternative of course, adding new methods while keeping the old ones is the only way to edit an append-only standard like the web.

I kinda like the way JS evolved into a modern language, where essentially ~everyone uses a linter that e.g. prevents the use of `var`. Sure, it's technically still in the language, but it's almost never used anymore. (Assuming transpilers have stopped outputting it, which I'm not confident about.)

for some values of "everyone" and "never".

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#35

Post by bulbar »

post-it wrote: post #13
voxic11 wrote: post #4

Earlier quoted context omitted.

The idea is you wouldn't mix innerHTML and setHTML, you would eliminate all usage of innerHTML and use the new setHTMLUnsafe if you needed the old functionality.

> you would eliminate all usage of innerHTML The mythical refactor where all deprecated code is replaced with modern code. I'm not sure it has ever happened. I don't have an alternative of course, adding new methods while keeping the old ones is the only way to edit an append-only standard like the web.

It for sure happens for drop in replacements.

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#36

Post by charcircuit »

josefx wrote: post #19
noduerme wrote: post #18

Earlier quoted context omitted.

Finally, a good use case for AI.

Wouldn't AI be trained on data using innerHTML?

Which is why it can easily understand how innerHTML is being used so that it can replace it with the right thing.

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#38

Post by orf »

croes wrote: post #23
voxic11 wrote: post #4

Earlier quoted context omitted.

The idea is you wouldn't mix innerHTML and setHTML, you would eliminate all usage of innerHTML and use the new setHTMLUnsafe if you needed the old functionality.

If I need the old functionality why not stick to innerHTML?

because the "unsafe" suffix conveys information to the reader, whereas `innherHTML` does not?

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#39

Post by fragmede »

stvltvs wrote: post #37
josefx wrote: post #19

Earlier quoted context omitted.

Wouldn't AI be trained on data using innerHTML?

Honest question: Is there a way to get an LLM to stop emitting deprecated code?

Theoretically, if you could train your own, and remove all references to the deprecated code in the training data, it wouldn't be able to emit deprecated code. Realistically that ability is out of reach at the hobbiest level so it will have to remain theoretical for at least a few more iterations of Moore's law.

Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148

#40

Post by reddalo »

voxic11 wrote: post #4
entuno wrote: post #2

This kind of thing always makes me nervous, because you end with a mix of methods where you can (supposedly) pass arbitrary user input to them and they'll safely handle it, and methods where you can't do that without introducing vulnerabilities - but it's not at all clear which is which from the names. Ideally you design that in from the state, so any dangerous functions are very clearly dangerous from the name. But…

The idea is you wouldn't mix innerHTML and setHTML, you would eliminate all usage of innerHTML and use the new setHTMLUnsafe if you needed the old functionality.

You can't rename an existing method. It would break compatibility with existing websites.
Post reply on HN