Firefox link doesn't work - suspicious copy in Firefox Add-ons catalog

[tigger04]

Love the idea of this project! Heard about it on twit.tv's Security Now podcast.

The Firefox link in the readme is broken.
I searched for it in the Firefox Add-ons catalog and found this - though the guy admits it is a copy and modified version of your original project. Unsure how safe it may be?

One more q - is there any other way to alert when changes take place to extension ownership. I'm using Arc desktop browser (Chromium based) which doesn't have the Chrome toolbar or ability to 'pin' this extension, an alert or something configurable would be really helpful.

Keep up the good work!

[msfrisbie]

That developer implemented it in response to issue 1 (#1). I don't know them. They offered to add me to the extension, I reached out and have not heard back.

The version published by me is out for review, it should be available very soon.

I explored options like showing notifications, I found them too annoying or invasive. Good feedback, perhaps I'll add it as an optional permission.

[msfrisbie]

Firefox addon was just approved

[maxtheaxe]

I apologize, I completely missed your email at the time—this is how I'm finding out about it.

I'm happy to add you to the listing, but before doing so and updating to the latest version of your code, I feel the need to ask you why you insist on routing firefox addon detail requests through your server, since responsibility for any data collection now also falls on me.

const installedExtensionIds = (await chrome.management.getAll()).map(
  (x) => x.id
)

const response = await fetch(
  `https://api.extensionboost.com/v1/developer?extension_ids=${installedExtensionIds.join(
    ","
  )}`,
  {
    headers: {
      "Content-Type": "application/json"
    }
  }
)

There's probably a valid argument for doing so, though I'm not sure I'd agree with it. Either way, before anything else happens, the README needs to be updated:

Why does this need an external server?
Browsers have special rules about modifying extension marketplace domains. For example, you cannot set declarative_net_request rules for chromewebstore.google.com. Therefore, this extension delegates the developer info checking to the ExBoost API server.

I'm sorry, but this whole thing gives me pause. Using my original implementation with a simple browser type check would have saved you time and effort, and despite that, you chose to move forward with routing traffic through the server for what is essentially an advertising platform you control.

[msfrisbie]

If my intentions are still in doubt, I encourage you to direct your attention to the agenda for today's WECG meeting, in which my own proposal to obviate the need for any third party server is being discussed: w3c/webextensions#556

---

I chose the current architecture for a few reasons:

Caching

The API endpoint implements three-tiered caching for requests:

1. Short-term Cache-Control header. Mitigates a portion of duplicate requests.
2. Caching entire API response. Similar reasoning to 1., but also encapsulates the idea that almost every request from a browser will be identical. Extensions are installed infrequently, and the extension sorts the IDs. When an extension ID is added or removed, there will necessarily be a cache miss, so the extension will reflect this change immediately.
3. Caching per-extensionId response. Extension installs follow a power law, so most people will have the same few extensions installed. No need to unnecessarily duplicate the request.
4. Rate limited responses. If the extension sends too many requests, it will ignore the 429 and wait for the next window to check.

Taking a peek at the server log query strings, some browsers have upwards of 50 extensions installed, and despite the structure of the extension, plenty of duplicate requests are being sent.

Code Maintenance

Chromium installs will outnumber Firefox installs 100 to 1, and probably more. That is just the reality of the browser landscape at the moment. Since most of the traffic needs to scrape, it's simpler for the extension to work identically across browsers, and for the server to separately manage Firefox/Chromium IDs. Furthermore, since the extension complexity is so low, fixes will likely fall on the backend, which I can deploy immediately rather than redeploying to two extension marketplaces.

Side Project

I run a lot of side projects off the same $5 DigitalOcean instance. This is one of them, ExBoost is one of them. They share some scraping code, it was more convenient for me. None of them generate any money.

[tigger04]

Nice work guys!