lfilho / sample-webextension Goto Github PK

Will assume a metrics service exist and only mock calls that would happen to such service instead. Will use localStorage under the hood instead.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization#Internationalizing_manifest.json

Acceptance criteria:

• AAC, I want to allow an endpoint present on the allow list to pass

See similar considerations about performance on #7

I'll also set up lint-staged and husky, so eslint and prettier run automatically before each commit, ensuring we always push formatted and linted files. :-)

"Friends": Babel, Webpack and ESM modules

I will decide later on if we need to use babel, weback or snowpack. Right now it seems the code will be simple enough, with very few dependencies, so we might not need the extra complexity of babel, webpack and etc.

If in the end we need it, I will consider Snowpack instead of webpack. Snowpack assumes we're running a modern browser, capable of ESM, so we wouldn't need webpack or babel transpilation when it comes to import syntax of ESM.

In the future, if needed, we could easily plug babel or snowpack in to generate a standar production bundle of the code.

Possible tests (to be expanded soon):

1. webRequest.onBeforeRequest at installation time
2. Any permission needed in order to send requests (contact form, sending metrics, etc)

Possible scenarios:

1. Blank profile (no extension installed before)
2. Profile with the extension already installed

The purpose of this task is get familiar with the basic steps to what it takes to package and release an extension. The extension itself won't have any use at this moment.

Acceptance criteria:

AAC, I want to be able to install the extension in my browser and see an alert box coming from it

Acceptance criteria:

• AAC, I want to be able to contact you from the extension about a bug or suggest a feature
• For this test project's sake, I will provide a simple UI that will eventually trigger a mailto: link.

With error codes, helpful debugging errors and also user-friendly errors that can be translated in the future

Remember to update the dev docs with it

One could argue we should private by default and in this situation block it instead.

The reasoning here is: deny lists are usually big lists not defined by the user (fetched by some general authoritative source -- like ourselves, EFF, etc). But allow lists are usually defined locally, by the users, so in that case we should trust they indeed wanted that override and hence use it as the driver of our decision here.

See #6

Jest will be used for unit testing. Later on we need to investigate if Jest can be a driver for playwright and the e2e tests.

Initial thoughts:

• Jest for unit testing and main driver
• Playwright for driving a browser and actually testing the extension -- I read somewhere recently that an extension can't be tested headless, so we would need a headful driver.
  • This might impact our ability to automatically test the extension via CI, meaning the automate tests would have to run in a developer's machine, or in a more expensive CI setup (one with a X / window manager available so we can install and run full browser in there)

When testing locally, web-ext tool abstracts some steps for us like installing it on the browser and giving the temporary permissions, so by running this test, without web-ext doing it for us, we ensure there's nothing web-ext is doing under the hood that might blindfold us later

To ensure there's not, for example, a lingering configuration that persisted from previous tests, or conflicting configuration from other extensions or browser configurations from other profiles.

Interesting tests to consider for later on:

1. 1 blank profile (no other extensions of custom configurations)
2. a profile with similar extensions (ublock origin, eff privacy badger, etc)
3. a profile that already has the extension installed
4. etc

Problem

Out automerge workflow checks for our ops-bot user in order to kick in and auto merge our release auto-cut PRs.

We're using a repo-scoped PAT (Personal Access Token). This mean that the github.actor in our github action will be whichever user generated that token (lfilho in this case).

See https://github.com/peter-evans/create-pull-request/blob/master/docs/concepts-guidelines.md#triggering-further-workflow-runs for more details.

Solution

We probably want to do https://github.com/peter-evans/create-pull-request/blob/master/docs/concepts-guidelines.md#push-pull-request-branches-to-a-fork as it's the most secure approach.

Temporary workaround

As I'm the only developer here so far, I have just changed the check to accept my username and instead I'm adding another condition to check for the specific automerge label.

First real release of a usable extension! 🎉

Acceptance criteria:

AAC, I want to access a site with a known tracker and not be tracked

Thoughts on performance

For this MVP we'll probably will go with a simple Set (<= O(n) as per javascript Set specification).
But for the future we need to consider the best data structure and matching algorithm for the deny / allow lists. Imaging they could get pretty huge, we need to consider performing cases like the ones below. But even then we should confirm those assumptions with load tests and some data gathering about how big those lists can realistically get.

• Adding matched trackers to a memory cache -- it's likely a webpage might call a certain tracker endpoint more than once throught their session, so we could avoid parsing the whole deny list and start looking on the cache instead.
• choosing a different data structure other than a set: maybe shard the trackers tld -> domain -> subdomain (similar to a dns lookup); maybe a BST; maybe a Trie?

Given the learnings from #4, automate

Acceptance criteria:

1. AAD, I want to have a script that generates the extension for me
2. AAD, I want CI to automatically run that script everytime the SemVer changes

This will be an important part for automatic releases and also tests.

By auto generating new releases we could later on even automate the upload of the latest releases to the browsers stores and our community could also subscribe to Github notifications and always be in the know when we release a new version.

We will use Github Actions but the necessary scripts will be written in a way we could easily port them to other platforms in the future if needed be.