Unfortunately, at this point I merged upstream changes from Mozilla into my Mercurial repository, only to find that there was now a compile error. I’m still figuring out exactly why this compile error is happening. It looks like it’s unrelated to any of the files that my patch touches; I suspect that it’s due to my general lack of competence with Mercurial (Mozilla’s codebase is the first time I’ve used Mercurial) or my similar general lack of competence with Mozilla’s build system.
So, until I actually get the code to build, I won’t be able to do performance evaluations of these changes. Hence why there are no pretty graphs in this post.
Meanwhile, I reached out to Mozilla to get some feedback on the general approach I was taking. (I had previously discussed high-level details with Mozilla, but this time I provided a WIP code patch, so that it would be easier to evaluate whether I was doing anything with the code that would be problematic.) This resulted in a discussion about what methods should be used to prevent malicious or buggy extensions from causing unexpected damage to user security. This is definitely a legitimate concern: messing with certificate verification is dangerous when done improperly, and it’s important that users understand what they’re getting when they install a WebExtension that might put them at risk. That discussion is still ongoing, and it’s not clear yet what the consensus will arrive at.
(It should be noted that there are some alternative approaches to Firefox support for Namecoin TLS underway as well, which will be covered in a future post.)
This work was funded by NLnet Foundation’s Internet Hardening Fund.