Live data from Hacker News

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

hacks.mozilla.org

171–172 of 172 posts

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

#171

Earlier 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.

It’s simple, you use innerHTML if you know for sure where the input comes from and if it’s safe (for example when you define it as a hard coded string in your own code). You use setHTML when you need to render HTML that is potentially unsafe (for example forum posts or IM messages). Honest question, which part of that isn’t clear?

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

#172
post #156

Earlier quoted context omitted.

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…

I thought you were done talking to me? Briefly though, if you have an untrusted string then you need to either treat it like text or sanitize it. I don't see any other options. So if people shouldn't use this sanitizer or write their own, then the only option left is treating the string as text. But you're vehemently arguing that's not what you said. What's the other way to use an untrusted string? Other than "don't"…

So "willfully".
Post reply on HN