Chrome Web Store review mistakes and inconsistencies

Question

Before deciding to write this issue on Stackoverflow, we tried everything that we could through the normal/official (and slow) contact process (contact form and developers emails).

So this is actually our last try to solve it and also expose some of the Google's review mistakes and inconsistency when reviewing new items (extensions).

We currently have an extension (item hjdkfeeffbfcoanbnkeedjccphcmpehm) that was approved and published few months ago and that is now used by more than 70,000 people, with excellent rating on Chrome Web Store.

https://chrome.google.com/webstore/detail/ad-block-chega-de-publici/hjdkfeeffbfcoanbnkeedjccphcmpehm?hl=pt-BR

This extension is an Ad Blocker and was primarily focused in the Brazilian market, for Portuguese-speaking people.

Due the success of this extension, last week we decided to add two new extensions (Ids: mmcgdfakfmbepgnoogipkccigohjjcim and hgekbffcnpflnhfjkdfdlhffigdfbnae) that would focus on English-speaking and Spanish-speaking countries and, when we tried to add these extensions with the exact same source code that we used for the item that is approved and published, the Chrome review team is always rejecting with these arguments below:

To have your item reinstated, please make any necessary changes to ensure:

• All of the files and code are included in the item’s package.
• All code inside the package is human readable (no obfuscated or minified code).
• Avoid requesting or executing remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests).

So, just to make it clear:

1) The extension that is currently approved and published (item hjdkfeeffbfcoanbnkeedjccphcmpehm) does have minified code and even so was approved.
Even so, we did what Chrome's team was requesting and uploaded new packages with human-readable code (not minified) and even so, again, our extensions were rejected;

2) The extension that is currently approved and published (item hjdkfeeffbfcoanbnkeedjccphcmpehm) does load dynamic content from our server, as we need to daily and automatically update our URL list for blocking ads, its impossible to simply build and publish a new extension version every time we need to block a new URL or type of Ad.
Ad Block Plus, uBlock and other Ad Blockers do the same and they are approved and published on the Chrome Web Store.

3) The extension source code of the new items, except by the text that needed to be changed, as the new extensions are in different languages (English and Spanish), is exact the same of the extension that is approved and published, line by line;
In order to prove that from them, we even created a diff file comparing line by line the source of the approved extension with the new extensions, even so this was not enough to prove them we were right and also to simply get some answer on our emails.

We have already argued all of that through email with Chrome's team, but never received any answer or reply, except by the standard "rejection and removal" emails. They simply don't care.

That being said, it's clear to me that:

• Google Chrome team is deliberately trying to prevent us for publishing two new Ad Blocker extensions, because they saw the growth that we had with our first extension (that is approved and published);

or

• Someone at Chrome's team is simply making repeated mistakes and no one cares nor read our emails;

I hope this message can help us get some human attention within Google's team and also alert you guys about the "really strange" problems that we are facing.

Answer 1

Although this issue was more related to Google's policies than programming in the first place, the solution is still relevant to share for other Chrome extension developers, as it was somehow related about how to load remote resources for your extensions.

After posting this issue Google's team contact us and their question for keeping rejecting our extensions was related to the way we were loading remote resources for our extension.

Google's reply by email

Your new extensions are fetching resource(s) from AAA.com.br. However, the official website(s) registered for your new items is BBB.com. This means that the resource(s) being fetched are coming from remote/third-party source(s) and as per our program policies, we had requested you to check the following:

• If all of the files and code are included in the item’s package,
• All code inside the package is human readable (no obfuscated or minified code), and
• If the items are requesting or executing any remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests)

The specific issue here is with #3.

It'll be great if you can give us some context on the resource that you're fetching and how the two websites in question are related. Once we have that information, we'll be happy to help you guys with the publishing process.

As we have two different URLs related to the same extensions (we have three extensions), for the new extensions the URL BBB.com was configured on Chrome Web Store Developers Console, but we were actually loading the resources from the URL AAA.com, that have being in use since we published our first extension.

Although both URLs were added and owner-validated to our Chrome Web Store Developers Console and both URLs were related to the same extensions, we now understood that is a good practice to load the resources from the URL that is actually configured on the extension details, even if you have more than one URL for the same extensions.

So, if you have URL AAA.com and BBB.com, and both are used for the extensions A and B, try to load the resources of the extension A from the URL AAA.com and the resources of the extension B from the URL BBB.com, even with both share the same backend.

This will avoid Google's team to think that you might be loading resources for your extension from unknown 3rd parties, that is forbidden according to the program policies.