151–160 of 172 posts
Earlier quoted context omitted.
This is a totally different kind of statement. You're not dividing tax returns into two categories and then saying what to do with each category. Those claims are different but not in a way that analogizes to the HTML conversation.
I'd say I'm interested in hearing how you reason that knowing whether you need to pay at least $1000 in unpaid taxes to the IRS doesn't put you in one bucket or another, but I'm not.
Earlier quoted context omitted.
They do link the default configuration for "safe": https://wicg.github.io/sanitizer-api/#built-in-safe-default-... But I agree, my default approach has usually been to only use innerText if it has untrusted content: So if their demo is this: container.SetHTML(` Hello, {name} `); Mine would be: let greetingHeader = container.CreateElement("h1"); greetingHeader.innerText = `Hello, {name}`;
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?
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
This is a totally different kind of statement. You're not dividing tax returns into two categories and then saying what to do with each category. Those claims are different but not in a way that analogizes to the HTML conversation.
I'd say I'm interested in hearing how you reason that knowing whether you need to pay at least $1000 in unpaid taxes to the IRS doesn't put you in one bucket or another, but I'm not.
Anyway, I see you edited your previous post after I wrote my reply.
If you weren't trying to divide things into two categories, you wrote it very confusingly. When you say how to handle trusted strings, then say how to handle untrusted strings, then say "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 really sounds like that's supposed that's supposed to cover all cases.
Me thinking you were using two categories is an honest mistake, not malicious misquoting.
And reading your original post that way is the interpretation that makes it stronger. If there are more categories then SetHTML is no longer "fundamentally confused". Your argument against it falls apart.
Earlier quoted context omitted.
I'd say I'm interested in hearing how you reason that knowing whether you need to pay at least $1000 in unpaid taxes to the IRS doesn't put you in one bucket or another, but I'm not.
The IRS thing indirectly has categories but it doesn't say what to do with them, and what to do with them is what I disagreed with your original post on. I didn't say all input is untrusted or whatever analogizes to your tax thing. Anyway, I see you edited your previous post after I wrote my reply. If you weren't trying to divide things into two categories, you wrote it very confusingly. When you say how to handle tr…
Earlier quoted context omitted.
> it's not at all clear which is which from the names. Ideally you design that in from the [start] It was, and there is: setting elementNode.textContent is safe for untrusted inputs, and setting elementNode.innerHTML is unsafe for untrusted inputs. The former will escape everything, and the latter won't escape anything. You are right that these "sanitizers" are fundamentally confused: > "HTML sanitization" is never g…
> 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'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 doesn't make sense for someone, presented with I did write, to strenuously argue with me that such a tortured, implausible, uncharitable, non-sensical interpretation of what I wrote was something that I have to account for (versus the interpretation that does match what I wrote and is actually true and makes sense).
You are, willfully or not, misconstruing what I have written.
> That's way better than telling everyone to write their own; it's not trivial.
Right, it's not trivial. It's so far the opposite of trivial that it's (as I said the first time—and again, just now) not solvable.
No one should be writing their own.
No one should be trying to write their own.
No one should be using this API at all.
And no one should have pushed for its implementation.
It's a bad API.
Earlier 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…
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", but that means not taking input and only works for toy apps.
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"…
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"…