Re: [whatwg/dom] [Declarative Shadow DOM] How should we build the "opt-in" for fragment parsing of declarative Shadow DOM? (#912)

My issue is with the introduction of a new sink, a variant of which needs to be unsafe to support DSD case (+ we don't actually have a way of adding a safe sink _yet_ via sanitizer, Trusted Types or both; every new sink is unsafe). 

I don't think naming a sink as unsafe is a sufficient bar. That said, `unsafeSetInnerHTML(payload, options)` is probably better than `setInnerHTML(payload, optionsWithUnsafe)`; at least it's greppable and could be discovered easier. Adding new sinks is not great, as all existing infrastructure, education materials etc. authors use to help them secure their code needs to be updated. For example, in Google there's at least two static analysis frameworks that now need to cover `setInnerHtml` to stop our engineers from accidentally introduce XSS (and we *know* by now that scary names simply don't work as a vuln prevention mechanism). So, if one squints, a document state + existing sinks would be a _safer_ choice here. 

All that said, security is not the only aspect, and this is not the only way to evaluate the security of this choice either. I'm not the decider here - the DOM editors are.

-- 
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-732251204