This will fail on input like"<img src='/path/to/src' onload='finished(this)' data-onload='true'/>" (attribute collision) or"Example vulnerability: <pre><img onerror='alert(\"Pwned!\")'/></pre>" (content alteration). I think consistency trumps security here, and we have to reject this approach.

Ok, I understand your first point, but the second example (content alteration) is desired in this case, disabling the XSS vector. This alteration doesn't differ much from removing<script>alert(1)</script> whenkeepScripts is not passed. As I've explained in the commit message, I don't see a safe and future-proof way to remove the event handler entirely.

So maybe a different valid prefix would be a middle ground we could agree on?

No, I meant that in the sense of altering elementcontent instead ofattributes (which is certainlynot desired). The difference is substantial: imagine the effects of this PR on$el.html( "Example vulnerability: <pre><img onerror='alert(\"Pwned!\")'/></pre>" ).

So maybe a different valid prefix would be a middle ground we could agree on?

There's no prefix that can both produce valid output and avoid attribute collision in all cases, but the value ofjQuery.expando is close enough that we could safely pretend. However, even disregarding the above issue (which I'm not prepared to do), there's still either a) the unrequested alteration of input, or b) the performance hit of revisiting newly-created elements to undo it, neither of which I like.

Personally, I prefer encouraging everyone to sanitize user input before passing it to jQuery as HTML (or better yet—not doing so) over paying the size/performance/complexity/maintenance costs of trying to solve every edge case ourselves.

Ah, now I got you. Ok, this might indeed be an unwanted side effect.