malte311 / fpfool Goto Github PK

Maybe the extension could start its work again after some time after it has finished its work.

The extension page (the page which is loaded when clicking on the extension icon next to the search bar) could display some statistics, e.g.

• Total amount of visited sites
• Total amount of clicked links
• Total amount of searches (maybe even more details about the search terms)
• ...

The tool does not detect all input fields correctly at the moment. This should change.

Add an user interface to make the application parameterizable.

Maybe TravisCI can be used to automatically deploy the extension.

Do not add keywords multiple times to indexedDB. Maybe use timestamps to make sure we did not add an entry before.

Use TravisCI for automatically generating JSDoc on gh-pages branch.

Mark sites on which searching failed as non-searchable.

The following algorithms need to be implemented:

• The default algorithm - execDefault() (maybe just open a connection and do nothing, then close the connection after a while)
• The history algorithm - execHistory() (especially update the browserHistory variable after visiting sites and remember to keep it up to date even in case the history gets cleaned up)
• ...

Some more ideas to improve this algorithm:

• Choose entries based on time interval (changeable)
• Choose entries based on a number (changeable)
• Open random sites in addition to sites from history
• Open sites which are connected to sites from history (use a tool like Lightbeam for this)
• How often visit sites? Be careful of captchas or similar things.

Searching and navigating on a page leads to a redirect. The redirect leads to a reload of the content script and therefore the disconnect call does not come through.

Take a look at IndexedDB and maybe use it for search term generation.

See title. Maybe use a new branch.

We can not get search terms from many urls at the moment. It works only for a small number of sites. The goal is that this works for more sites.

After a while in the browser, even without closing the window, the extension seems to start again. It should not restart in the mid of a session - only at the beginning of a new session.

When saving the queue, the size can explode. Either do not save the queue, i.e., reset it on every browser restart, or make sure it's size does not explode.

Creating always the same fake connections could have contra-productive effects. Therefore, the idea is to change the algorithm based on some criteria. These criteria could be:

• The device (use a different algorithm for a different device). Maybe we could use a fingerprint in order to make this happen.
• ...

Removing tabs from the currentTabs array causes trouble when multiple content scripts are executed at once.

When content scripts are working in parallel, they close their tabs in parallel, which leads to removing tabs from the currentTabs array simultaneously.
In addition to that, there is a chance that at the same time a different content script asks if it should get executed ('isExec'), which can lead to a undefined response message.

Maybe it could be useful to have a .json file containing constants.
At the moment, some constants are declared multiple times, because they are in different scopes (e.g. one time in content script and another time in background script). If one wants to change a constant, then it has to be changed at two different places, which is not preferable.

Since this extension visits websites, these websites are saved in the user's browser history. This can be confusing to the user because he or she did not visit these sites at all.

Therefore, it could be a good idea to clean up the history every time a tab has been closed (or whenever the browser is quit, i.e. the onSuspend event is fired).

It could be useful to display the id of the corresponding tab as well.

Each tab should execute the content script, such that each tab independently searches and navigates.

Databases should get a clean up such that only recent activity is relevant.

Add functionality to the "Reset statistics" button.

At the moment, the extension does not keep the usual window size. The problem is that the hidden window gets closed after the real window such that chrome saves the size of the hidden window for the next start.

At the moment, the extension does not close the extra window in case the user closes his real browser window.
Maybe it could even be useful to not close the extra window. In this case: When should the window be closed?

Limit the number of tabs at the same time.

Choose terms randomly, even if the first try fails. At the moment only the first try is random, afterwards we choose sequentially.

Statistics are loaded only once. They should be updated when the page is kept open and some values change.

Use the chrome.storage.sync api to store the queue persistently. We could do the same with the browser history.

In order to make the behavior of the extension to look like a real human interaction, there should be some delays:

• No instant clicks on links
• No instant searches
• Staying on a site for some time (this time could be used to simulate scrolling)
• ...

Create a readme.md file containing relevant information for this project.

When search params do not exist yet, wait for the next getSearchTerm(...) call until the first call is over, because the first call will get the search params such that the following calls do not need to do the same work again.

Current formula is connectionLimit = result.connectionLimitFactor * sum;.
Problem is that the sum of visits increases due to the extension. This means that the limit increases from day to day, which should not happen.

If a search param is not found, we get it. After this, we can get the search terms as well.

Searching for random words is not the most realistic way to search for something. Therefore, it could be useful to adopt the searching algorithm. Some ideas:

• Choose the search term from a dictionary (which is in fact searching for random words). Save the dictionary in an extra file (preferably .json)
• Choose the search term based on previous searches
• Use a tool to find corresponding words to previous searches and search for these corresponding words instead
• Use a tool to find opposite words to previous searches and search for these opposite words instead
• ...

Dummy searches are being deleted, but it seems that this does not work always. The database should not contain any dummy search terms!

Fill database with travel related entries.

Search terms should be available for all domains of the same website, e.g. google.com and google.com/search should be able to use the same search terms. This should also apply to subdomains.

Remove the Max. history entries setting and add a Max. number of tabs setting instead.

The size is limited to maxConnectCount, which is now a scaling factor only. It should be rather set to connectionLimit.

Tabs should be limited in order to prevent the tool from crashing due to too much cpu workload.

Now, don't just take the same words a user already searched for. Instead, use the database to generate a new search term which should be antonym to the original one.

Maybe use persistent storage for

• third-party requests and
• browser history.