The state space is too large for these algorithms to be effective on Firefox as a whole, and there are many libraries we just don't care about when browser fuzzing.
eg. if AFL/libFuzzer manages to hit a path that makes an input appear as gz encoded, the "novel" zlib coverage is very attractive to the algorithm, but that's a very inefficient way to fuzz zlib.
Most of these libraries are targeted specifically by OSS-Fuzz [0] and their integration into Firefox is fuzzed with libFuzzer using the fuzzing interface andrei mentioned.
AFL is not that smart. If you only do bit flippings on the inputs, then fuzzing a JavaScript engine/dom engine will take forever. The "domino" (Mozilla internal tool) looks quite powerful as it generates semantically correct dom. Sadly, it is not open source. Google has a tool designed specifically to fuzz JavaScript engines, Fuzzilli[1], which hackers have been using for bug hunting.
I wonder why domino hasn't been released? Is Mozilla selling it to other companies?
Because it often finds security issues in our code: see the graph at the end of the blog post.
If opensource, this fuzzer could be used against our users...
AFAIK, Mozilla doesn't sell any software!
Mozilla sells VPN products ;) But no, not these tools.
VPN products are more like a service than selling software.
What about the decrease in paid security professionals?
I believe they use libfuzzer to test isolated components [0], but seems like they wanted to specifically focus on browser fuzzing for this post (it's probably more interesting, too).
[0]: https://firefox-source-docs.mozilla.org/tools/fuzzing/fuzzin...
I wonder why that is— that always struck me as a particular elegant approach, and I know AFL has been used to find tons of bugs in various popular open source projects. There was a popular article on HN a while back where AFL even “learned” how to generate valid jpg image file headers.