3 ms·
> - you don’t need to add apis to Firefox to use them in an Electron app Right, so what? > - It isn’t hard to do what this api does in Javascript as fast as t
by fabiospampinato 5y ago
> - you don’t need to add apis to Firefox to use them in an Electron app
Right, so what?
> - It isn’t hard to do what this api does in Javascript as fast as the browser can do it. There already is api to convert strings to DOM and it isn’t exactly rocket science to iterate over the result and drop tags that aren’t on a list. I’m sure there can be a library that does it slowly but it doesn’t have to.
Of course it's DOMPurify's fault for being that slow, nobody is arguing that it must be rewritten in C++ to be fast.
It's not as simple as you put it though, unless you have an extremely strict list of tags containing no tags in which case it's trivial, but it's also of very little use.
Since your comment sounds overly arrogant to my ears I'd like to point out that by following the rules that you mentioned for making a sanitizer (DOMParser + drop non-whitelisted tags basically) you can only produce either a useless or a broken sanitizer, it's impossible to make a useful and working sanitizer that way. Proof-ish: either you drop <img> nodes, in which case you've made a pretty useless sanitizer in my book, or you leave it in, in which case you leave yourself open to XSS via stuff like the onerror attribute.
It's not trivial to write a sanitizer that both works and it's useful, almost no developers should need to learn all the nuances necessary for writing one, hence the platform itself should provide it.
- tinus_hn 5y agoWhy would you need to allow any attribute you don’t know? The ‘trick’ which has been known since the turn of the century is to have a whitelist of things to allow and block everything else. So you allow img tags with the attributes you know and drop everything else. And if it’s useful to have a prepared list of safe tags, why would that need to be provided by the browser? > It's not trivial to write a sanitizer that both works and it's useful While I would disagree with this claim, if it is true it is even more reason to not set this in stone by building it into browsers and instead provide a basic external library that makes the policy decisions that are useful to you. And of course this is what is going to happen anyway, because you can’t count on this always being available, so you need to include a library that provides this functionality in JavaScript if the browser doesn’t. Which is trivial because this doesn’t involve anything JavaScript doesn’t have access to.