Addon disabled because of using eval

URL: https://addons.mozilla.org/zh-CN/firefox/addon/quicker-connector/
I have replyed the email, but still no response.

Using eval is by desigin, that’s how this extension works.
Custom scripts are from users, actions triggered by users.

This extension is designed to run user defined code from ‘Quicker’ application to control webpages or browsers.

The chrome version of this extension has been released for several months and has more than 3000 installations. Link

Many users request Edge and Firefox versions. So I just made this one.

The edge version with same code also passed certification: link

Quicker is a windows software that allows users to create many actions and trigger action when they need. (Home page : https://getquicker.net)

Action was built using ‘Blocks’, each Block is just like a method in programming language.

‘Browser Control Block’ is one of them. It allows users to perform automatic operations on browsers.

The extension needs to use eval to run the background script to realize these functions.

Here’s a example to fill web form:

Here is an example to control browser (close tabs on left side) :

Another sample action to sort browser tabs by title or url:

By running custom scripts, users can perform actions with great flexibility.

I have no way to change code and still make this work.

Please do not disable it, thanks.

I think the main problem with eval in extensions is that it has access to WebExtension API.
In Firefox there is special API for executing user scripts (without WebExtension API access but with full DOM access).

For your use-case this should work fine and should be easy to implement.

Another way is to not host your extension on AMO but host it yourself.

The UserScripts is content scripts that control Web Pages but not Browser it’self.

Eval() was used to execute scripts running on the ‘Background Page’, which call browser apis to control browser. Just like the last two examples in my main post. I am using ‘chrome.tabs’ api to control browser tabs.

This extension is fully open soured on github.com, it will only work with the Quicker software, it will not connect any server.
The scripts are from user, actions are triggered by user and permissions are controled by user.

I see… yes this is bad :frowning:.

You see, this is a remote code execution. Even though your extension is open source and it behaves fine, it can change to malicious simply by executing malicious script from the external app.
To make it safe, you should have a defined fixed API between your external app and the extension. So that reviewer can see that only these commands can be executed.

Or the self-hosting, skipping the AMO…

Thank you. I will learn how to self host…

Please note that our policies apply both to listed and self-hosted add-ons, therefore using eval to execute code received from a native messaging host is not permitted either. Having a more defined API that processes requests from the native messaging host in a safe way would more likely pass our review. The requests should be on the level of “move tabs to the left”, not “pass requested parameters to the tabs API”.

I understand this may limit the functionality of your add-on, though unfortunately we cannot accept code to be executed through a native messaging program.

1 Like

I have searched ‘RPA’ from store, and checked first 3 add-ons, each one has eval code.

Kantu:


IS-RPA


OpenRPA


Rpa Native Message Plugin


My software is RPA kind, why blocked?

I create this add-on for users who use firefox, even the number is very small, they like firefox and they want the function my software provide.

I jsut feel sad for those users.

1 Like

I agree that it is unfortunate, I would have loved come back with news. These add-ons look like they have a good use case and aim to provide the user with a convenient feature. Unfortunately though we cannot trust data coming in this way as we would need to additionally review the native messaging program.

Thank you for letting us know about the other add-ons, we will take a look to see if they are compliant with our policies.

If the policy is ‘using eval to execute code received from a native messaging host is not permitted’ , I think you should block all add-ons which declared ‘unsafe-eval’ permission type and totally remove this ‘unsafe-eval’ permission type from API, and declare this in developer documents.

Thank you for the feedback. We don’t allow execution of remote code, and with native messaging we consider this remote code. I’ll put this on the list of clarifications for the next policy update. There are select valid use cases of unsafe-eval, but we’re looking to see if we can restrict this further so it becomes more obvious during development, letting developers know earlier in the process.

I think you will also agree that if something is desiged, it should consider the good of users.
Maybe sometimes it’s better to leave the choise to users , show warnings and give them choise.

For my extension, it only works with the desktop application, only users of my desktop application need this extension.
If there is some conditions that eval should be allowed, I think this should be one.