- From: Krzysztof Kotowicz <notifications@github.com>
- Date: Thu, 12 Nov 2020 07:29:08 -0800
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Thursday, 12 November 2020 15:29:22 UTC
> This sounds good overall, except that I'd wait with introducing `setInnerHTML` until we have a standardized sanitizer (see https://github.com/WICG/sanitizer-api) as not using the sanitizer should be an opt-out (labeled "unsafe"). Introducing another API that will incur XSS does not really seem acceptable to me. Isn't this more of an argument for Trusted-Types-like guards on this sink? Sanitizer API leans into the direction of unconditionally removing JS code, and this sink needs to, at least optionally, support JS in HTML. So we'd either end up with two different sinks (`unsafeSetInnerHTML(string)`, and `setInnerHTML(stringToSanitize)`), or an additional argument for both variants. It seems more elegant to just cover it with Trusted Types guards instead, or only require `TrustedHTML` with no option for a string. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/912#issuecomment-726149709
Received on Thursday, 12 November 2020 15:29:22 UTC