Another example, from only seven months ago, is this discussion of how to eliminate XSS attack vectors from the "CommonMark" markdown standard: http://talk.com

Another example, from only seven months ago, is this discussion of how to eliminate XSS attack vectors from the "CommonMark" markdown standard: http://talk.commonmark.org/t/make-commonmark-safe-by-default/1265/10 http://talk.commonmark.org/t/make-commonmark-safe-by-default... The proposal being made, as per my understanding, is that by default CommonMark-compliant markdown should be evaluated in a "safe" mode--escaping html and whitelisting url formats--and that compliance with this behavior among interpreters should be enforced by the validation tools provided by CommonMark. This would conceivably result in CommonMark markdown becoming an easy default way to eliminate the possibility of XSS on sites that accept user-input in the form of comments, etc. Unfortunately, the conclusion to the discussion seems to have been, "although it seems to be possible to trivially eliminate XSS attacks from user input using 'safe' markdown, that's an implementation detail so it's not the job of the standard". I only found this yesterday, and I'm still trying to understand the current stance the project is taking on this (I don't know if it has changed), but I think it underlines how important--and uncommon--it is for people to adopt an attitude of "if we can eliminate a class of attack through a formalism or technology, let's do it." If CommonMark were to adopt this approach, it could make the security advice given for processing user input as simple as "use a CommonMark-compliant markdown interpreter in the default 'safe' mode", whereas now it seems to be, "pick the right markdown interpreter that has a 'safe' mode you can trust, be sure to configure it properly, and then for good measure take the computationally expensive step of running your generated HTML through a sanitizer."