This is good. All of this stuff is possible to do already with 3rd-party frameworks with varying levels of performance/reliability, and there may be other meth

This is good. All of this stuff is possible to do already with 3rd-party frameworks with varying levels of performance/reliability, and there may be other methods you use to sanitize your output. If you're a responsible developer, if you have experience trying to guard against XSS, or if you're working with a framework like React/Vue/whatever, this may not change much about your life. However, I think it's understated how many sites struggle with this, and how many of them do sanitization poorly, and it is much better to be able to point them towards a single API and say, "look, just call this function." One of the bigger vulnerabilities I've ever found in a website (https://danshumway.com/blog/gamasutra-vulnerabilities/ https://danshumway.com/blog/gamasutra-vulnerabilities/) was in part a problem directly caused by bad sanitization. When I reported that vulnerability, I didn't advise them to fix their sanitizer because I didn't feel confident it would really fix the problem or that there wouldn't be other issues in the future. I could have pointed them towards something like DOMPurify, but instead I advised that they start embedding posts in iFrames with reduce permissions so any scripts that did run wouldn't be able to get at user data. I wonder if there was more of a standard around this stuff if some engineer on their team might not have caught the problem earlier. Similar to the SameSite changes to cookies, getting a native sanitizer isn't about forcing you to stop doing serverside sanitization or even changing your workflow much at all. It's about making the defaults safer and making it easier for hobby developers (and companies too) to avoid messing up because they don't understand the risks of calling otherwise innocuous functions. What's even more exciting is some of the work going into trusted types (https://web.dev/trusted-types/ https://web.dev/trusted-types/). The sanitizer API gives you a function you can call to get reasonably safe output without a lot of configuration or a 3rd-party framework or knowing what to download. The trusted types API is designed to make it harder to accidentally go outside of that sanitizer. It's not a silver bullet, but it's a big deal for companies where you're trying to set org-wide policies and avoid XSS attacks sneaking in through a random feature by a team that you're not watching closely enough. It's promising to see Firefox/Google working together on this stuff, I hope they continue with other APIs. The ideas are good, they just need iteration and more input, and these kinds of API areas are imo where Google/Mozilla tend to work together pretty well. I'm fairly optimistic about them.