Obfuscated code in unlisted add ons - allowed?

In the blog post Add-on Policy and Process Updates @caitmuenster writes that:

We will no longer accept extensions that contain obfuscated code.”

My question is if this goes for unlisted add ons as well?

I have a commercial add on that users pay for. With no obfuscation I would be giving the source code away and have a cracked version out in no time. In short 5 years of work and a major investment would be lost. Any comments on that?

1 Like


I would really like some clarification for this question. It is extremely important to anyone who hope to develop commercial add ons for Firefox.

Yes, this includes unlisted/self-hosted add-ons as well.

Obfuscation is not a good way to protect your IP. Obfuscation does not properly protect your source code, as with enough effort, (almost) every obfuscation can be reverse-engineered.

1 Like

Is there a better way?

Sure. The intention is not to create 100% protection, that is not possible. But when you make it so time consuming to reverse engineer the code, that you could just as well write new code from scratch, then the effort required becomes so huge, that it makes no sense to undertake the task.

With obfuscation tools like http://jasob.com/ you can effectively protect you code. It has been working for 5 years for me.

How can no protection at all be a better option? It is like leaving the keys in your car and the door open because… If someone puts in some effort they can steal it anyway.

Please do reply as I need to make a decision whether or not to stop a project that I have invested countless hours in and roughly $60.000. It is not a joke.

Can I take from the lack of reply. That add on developers will have absolutely no way to protect there code in the future of Mozilla and Firefox?

I would really appreciate some form og reply as this is not a minor change but a huge one. Just confirm, that all add on code will be exposed, so I can move on and look for other platforms.

Obfuscation won’t protect your code and can easily be reverted. Remember minification is still allowed and it is a thing that cannot be 100%ly inverted (as e.g. one cannot recover variable names).

That said, I wonder if wasm would be a “good” alternative to “protecting” one’s source code if one really wanted to. Since it’s just extreme minifaction (okay, it may not be the solution yet due to limitations of wasm).

Is it is easy to reverse engineer 5000 lines of obfuscated code? I mean sure it can be done, but it is not easy as in no effort required. It will take several days/weeks to fully understand and clean up the code. Sure you can use a beautyfier to get the initial structure, but after that that it is a tedious job to figure out the code.

As I wrote above the idea of obfuscation is not to achieve 100% protection. That is not possible for any client side code. The idea is to make it harder, so it requires at least some effort as opposed to no effort at all.

We put fences around our houses and locks on our doors. Even though we know that anyone who put in some effort can jump the fence and force the door open. It is a terrible level of protection and yet it is sufficient.

Mozilla are now asking developers to remove the door from there home, so that anyone can walk right in.

Obfuscation is not perfect, but it the best we got and it is better than most people think. Now Mozilla has decided that no protection at all is just as good as some protetion. It makes no sence and it will keep me and many others from spending time on add on development for Firefox.

When Google blocked obfuscated code, the reason behind was this:

Today over 70% of malicious and policy violating extensions that we block from Chrome Web Store contain obfuscated code. At the same time, because obfuscation is mainly used to conceal code functionality, it adds a great deal of complexity to our review process. This is no longer acceptable given the aforementioned review process changes.

Read whole blog here.

I think the same applies here.
Mozilla moved from manual reviews to automatic where the initial check is done by machine - which may have problems finding common malicious patterns in obfuscated code.

But I guess it would be reasonable to allow obfuscated code for “validated” developers.

Anyway, I would say that thanks to minification you can still have your “fence” / “door”, it’s just a bit smaller than before. Sure it’s easier to find out what makes it tick, but extracting whole features is still quite an impossible task.