Earlier quoted context omitted.
If I need the old functionality why not stick to innerHTML?
Because sooner or later it'll be removed.
No because the web has to remain backwards compatible with older sites. This has always been the case.
Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
111–120 of 172 posts
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#112Kids in the '90s:
SQL("select * from user where name = " + name);
div.innerHTML = "Hello " + user.name;Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#113So you can still inject or ... etc into your username, in the given example Preventing one bug class (script execution) is good, but this still allows arbitrary markup to the page (even CSS rules) if I'm reading the docs correctly. You could give Paypal a fresh look for anyone who opens your profile page, if they use this. Who would ever want this?
> Who would ever want this? Anyone who wants to provide some level of flexibility but within bounds. Say, you want to allow and in a forum post but not . It's not too difficult to imagine uses.
Forums would already have code that sanitizes user input when it's submitted. Users aren't directly setting html elements.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#114Earlier quoted context omitted.
> Who would ever want this? Anyone who wants to provide some level of flexibility but within bounds. Say, you want to allow and in a forum post but not . It's not too difficult to imagine uses.
Forums would already have code that sanitizes user input when it's submitted. Users aren't directly setting html elements.
And is that sanitization perfect? Kept up to date?
With a safe API like this one that's tied to the browser's own interpretation of HTML (i.e. it is perfectly placed to know exactly what is and isn't dangerous given it is the one rendering it) wouldn't it be much better to rely on that?
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#115Earlier quoted context omitted.
Any potential reader should be familiar with innerHTML.
Right. Like how any potential reader is familiar with the risks of sql injection which is why nothing has ever been hacked that way. Or how any potential driver is familiar with seat belts which is why everybody wears them and nobody’s been thrown from a car since they were invented.
[deleted]
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#116Earlier quoted context omitted.
But if some are marked unsafe and others are not it gives a false sense of security if something is not marked unsafe.
So we shouldn’t mark anything as unsafe then? And give no indication whatsoever? The issue isn’t that the word “safe” doesn’t appear in safe variants, it’s that “unsafe” makes your intentions clear: “I know this is unsafe, but it’s fine because of X and Y”.
Maybe we should add the word safe and consider everything else as unsafe
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#117Earlier quoted context omitted.
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.
> When the condition for when you want to replace is hard to properly specify, AI shines for such find and replaces.
And, in your opinion, this is one of those cases?
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#118So you can still inject or ... etc into your username, in the given example Preventing one bug class (script execution) is good, but this still allows arbitrary markup to the page (even CSS rules) if I'm reading the docs correctly. You could give Paypal a fresh look for anyone who opens your profile page, if they use this. Who would ever want this?
> Who would ever want this?
Your lack of imagination is disturbing :-)
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#119Earlier quoted context omitted.
> Shouldn't use innerText anyway (nonstandard, worse performance, tries to parse the HTML and gives you unexpected behavior if e.g. a style is set that makes an element invisible but still has text inside, doesn't work on all DOM nodes...) Maybe you meant .innerHTML? .innerText AFAIK doesn't try to parse HTML (why would it?), but I don't understand what you mean with nonstandard, both .innerHTML and .innerText are pa…
> maybe third time could be the charm: it's for preventing XSS holes That information is in the question, so sadly no this still doesn't make sense to me because I don't understand any scenario in which this is what the developer wants. You always still need more code (to filter the right tags) or can just use textContent (separating data and code completely, imo the recommended solution) > Maybe you meant .innerHTML…
> I don't understand any scenario in which this is what the developer wants.
Client-side includes.
Re: Goodbye InnerHTML, Hello SetHTML: Stronger XSS Protection in Firefox 148
#120Earlier 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.)