What's the benefit over Trusted Types?
Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
161–170 of 172 posts
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#162Earlier quoted context omitted.
You'd never want to store the processed HTML anyway, this is website building 101.
I store both, to serve processed HTML faster, and to be able to rebuild it just in case. Is this ok?
I wouldn't trust myself to always remember to sanitize it, and in a company with more than one person, it becomes impossible to ensure it is properly handled.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#163Earlier quoted context omitted.
`setHTML` is meant as a replacement for `innerHTML`. In the use case you describe, you would have never wanted `innerHTML` anyway. You'd want `innerText` or `textContent`.
But that's what setHTML isn't at all a replacement for innerHTML. You still need innerHTML when you want to inject HTML tags in the page, and you could already use innerText when you didn't want to. Having something in between is seriously useless.
> need innerHTML
parent.appendChild(document.createElement(tag))
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#164Earlier quoted context omitted.
What if I wanted an ? Edit: I don't mean this flippantly. If I want to render, say, my blog entry on your site, will I need to select every markup element from a dropdown list of custom elements that only accept text a la Wordpress?
If it's anything complex I'm doing it server side, personally
That works fine. That said, client side JS solutions are already quite popular.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#165This 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…
Yeah someone tells me something has been made “safe” is nice but unless I know exactly what that means … it’s easy to say safe by someone who doesn’t have to deal with it when the bad corner case happens.
Oh and it’s safe… in this browser… not that one, so this idea of safety is kinda dead to me for now.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#166Earlier quoted context omitted.
But that's what setHTML isn't at all a replacement for innerHTML. You still need innerHTML when you want to inject HTML tags in the page, and you could already use innerText when you didn't want to. Having something in between is seriously useless.
> need innerHTML parent.appendChild(document.createElement(tag))
How is adding an element to the parent the same as replacing all the content of the element? You guys are exhausting. Think a bit before spouting nonsense?
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#167Earlier quoted context omitted.
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.)
I touch JS that uses var heavily on a daily basis and I would be incredibly surprised to find out that I am alone in that.
That is indeed why I added qualifiers to "everyone" and "never".
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#168Earlier quoted context omitted.
> There's no getting around knowing whether or any arbitrary string is legitimate markup from a trusted source or some untrusted input that needs to be treated like text. This is a hard requirement. It is not a hard requirement that untrusted input is "treated like text". And this API lets you customize exactly what tags/attributes are allowed in the untrusted input. That's way better than telling everyone to write t…
It is not a hard requirement that untrusted input is "treated like text". It's also not a hard requirement that I defend the position that there's a hard requirement for untrusted input to be treated like text. That isn't my position, and it's not what I wrote. Given that it is not a hard requirement that untrusted input be treated like text, it wouldn't make sense for anyone to claim that it is—and therefore it does…
[deleted]
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#169Earlier quoted context omitted.
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…
> "ES6 being too new to be standard knowledge" Huh? It's been a decade.
Exactly, I learned coding JS before 2015 (it was my first language, picked up during what is probably called middle school in english). I haven't had to learn it again from scratch, so I need to go out of my way to find if there is maybe a better way to do the thing I can already do fine. It's not automatic knowledge, yet the LLM seems to have no trouble with it, so I'm pointing out that they seem to not have problems upgrading. The grandparent comment suggested it would need to be trained anew to use this new method instead. Given how much old (non-ES6) JS there is, apparently it gets it quite easily so any update that includes some amount of this new code will probably do it just fine
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#170Earlier quoted context omitted.
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…
ES6 is 11 years old. It's not that new.
Hence the example of how long it takes non-LLMs to pick that up, whereas LLMs seem to get it despite there being loads of old code out there
See also my reply to the sibling comment with the same remark https://news.ycombinator.com/item?id=47151211
My mistake for saying 10 instead of 11 years btw, but I don't think it changes the point