My thoughts as a maintainer of a HTML sanitizer in Go https://github.com/microcosm-cc/bluemonday https://github.com/microcosm-cc/bluemonday which is also availa

My thoughts as a maintainer of a HTML sanitizer in Go https://github.com/microcosm-cc/bluemonday https://github.com/microcosm-cc/bluemonday which is also available to Python via https://github.com/ColdHeat/pybluemonday https://github.com/ColdHeat/pybluemonday 1. Sanitizing is not difficult, defining the policy/config is. This is difficult as your need is not someone else's. First glance of this proposal is that this needs a lot more work to cover people's needs. It's good enough, but will have a lot of edges and will need to evolve. 2. If you allow a blocklist then it will be less secure. Because people will use that by default as it's easier to say "I don't want <blink>" than it is to say "I only accept <long list of things and the myriad of when attributes are valid on which elements>". The problem here is that a blocklist requires the person writing the config to cover every scenario to be safe and unless they're a security engineer they will not... and if they were a security engineer they'd use the allowlist. Blocklists seldom deliver good security, allowlists deliver great security. 3. Provide sane defaults. Most engineers simply do not know what is safe or not. I ship a policy in bluemonday for user generated content... it is safe by default and good enough for most people, and it can be taken and extended due to the way the API is structured so can cover other scenarios as a foundation policy. ----- I think the proposal in general: specify a standard for a sanitization API has merit. But mostly it has merit if it specifies a standard for defining sanitization policies/configuration, allowing them to be portable across different languages and systems. The one I wrote is very heavily inspired by https://github.com/owasp/java-html-sanitizer https://github.com/owasp/java-html-sanitizer which is the OWASP project one maintained by Mike Samuel. When I did my research before writing the Go one, this was far and away the best way to construct the policy/config and I already saw that this perspective was more valuable than whether it's a token based parser (GIGO but low memory) or a DOM builder (more memory)... no-one cares about the internals, they care about expressing what safe means to them.