Cool bug but “sanitizing” user input is usually not what you want. Instead the solution is to correctly parse and validate the user input, then later correctly serialize the data into the output format.
I think sanitize is short hand for correctly parse and validate and serialize.
In every instance where I ran into that when I worked in security the techniques described as “sanitization” were things like horrific regexes that stripped HTML tags, routines that backslash escaped some characters in parameters in incoming HTTP requests, or routines that removed “special” characters. For example: PHP’s documentation: http://php.net/manual/en/filter.filters.sanitize.php
Or all of the hits on Google for “sanitize input”: https://www.google.com/search?q=magic_quotes+sanitize
So, I wish that were what they meant but most likely not.
I guess all the better that Mozilla recently launched their own content blocker? Certainly makes sense to trust Mozilla as an organization and it’s publicly available source code until this is changed.
As stated in the article - the issue was reported by the author of an existing content blocker (Refine), and he only posted about it after Apple had released fixes for it.
I tried the Mozilla content blocker - feature wise it’s got nothing on Refine (or many others Im sure), and the authors actions here do more than enough to give me confidence that he values his user’s privacy.