What is Chrome actually reviewing during the "Pending Review" process? Any tips on speeding it up?

[Big Boy]

What is Chrome actually reviewing during the "Pending Review" process? Any tips on speeding it up? 

[Simeon Vincent]

The review team is processing other requests while your extension is pending review. Extensions that request more limited permissions are given higher priority. As such, the single best thing you can do to speed up review times is to remove "<all_urls>", "https://*/*", "http://*/*", and similar broad host permissions from your extension's permissions and content scripts. If possible, I'd also recommend moving from static content script injection in your manifest.json to dynamically injecting content scripts when the use triggers your extension via your browser action button, keyboard shortcuts, etc.

Simeon - @dotproto

Extensions Developer Advocate

[Big Boy]

Awesome. Thanks for the help. For private releases for specified accounts/testers, is the process usually just as long? 

[cgar...@att.net]

This is helpful information.
It does seem to be applicable only for those extensions set up to initiate interaction via browser_action.

Suppose however that the extension uses page_action because, although it is general purpose, it is only applicable to select pages (e.g., pages that
include a particular library. In order for the library to communicate to the extension that it is loaded and that the pageAction should be shown
(from which the user can then CHOOSE to activate the SDK for that library), then the content script (which 'bridges' communication of that fact)
must already be loaded ["run_at" : "document_start"]. So, although only tab/activeTab "permissions" are required for the "permissions" manifest key,
the "content_scripts" manifest key must still include a "matches": ["http://*/*"", "https://*/*"] because there is no aprior knowledge of the domain for the developer trying to use the SDK (the extension's front-end). This leads to a couple of questions -->

When you say 'remove <all_urls"... does this mean ALSO from the 'matches' subkey in content_scripts: manifest key?
If this is so, then how does one handle the Youssarian-paradox of dynamically injecting the script to tell the extension to dynamically inject the script?
I am sure I am missing something, I usually do?

Chrys

[PhistucK]

> If this is so, then how does one handle the Youssarian-paradox of dynamically injecting the script to tell the extension to dynamically inject the script?

I might be misinterpreting, but if this is your constraint, then I believe there is no way around it - the review time will simply be longer because you may be doing harmful stuff to the users without any interaction from their part (other than installing an extension).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/0118d583-617e-4710-aa2b-0e43bd2696bd%40chromium.org.

[Gildas]

I'm the author of SingleFile (ID: mpiodijhokgodhhofbcjdecpffjipkle). I forked it recently into an new extension called SingleFileZ (ID: offkdfbbigofcgdokjemgjpdockaafjg) which requires less permissions than SingleFile.

I have to wait 7 days to publish any bugfix for SingleFileZ while it takes no more than 1 hour for SingleFile to publish the same bugfix. Unfortunately, this is a personal project and I do not have the QA team you're requiring me to have. Indeed, SingleFile and SingleFileZ must be often updated because of bugfixes, deprecated features and new features added to the Web Platform. I'm seriously thinking about removing my extensions from the Chrome store because of this strong constraint which I consider harmful for users and obviously useless since the two extensions are almost the same...

Some years ago, I sent you a copy of my ID card because SingleFile was asking a permission for file:// URIs. What more should I do in order to have the right to publish SingleFileZ and SingleFile simultaneously on the Chrome store?

PS: reposted to fix typos

[Simeon Vincent]

Unfortunately I can't go into detail about the internals of the review process as we don't publicly discuss how this system works. What I can say is that the CWS and review teams are actively working on several different changes to the review process to combat malicious extensions and unwanted software. Among those changes is the adoption of a more defensive approach to permissions and development practices that are consistently used by malicious actors.

Regarding the difference in review time between SingleFile and SingleFileZ, I can only say that each extension is different. Review taking 1 hour for SingleFile vs 7 days for SingleFileZ is an artifact of this process and within my expectations of the current review queues. That said, we're aware of developer frustration around 7 day and longer review times and considering options here. We also need to make changes to better set developer expectations here.

As for what you can do to reduce review times, the single biggest thing you can do is remove broad host access like <all_urls>, https://*/*, http://*/*, etc. SingleFileZ is currently using <all_urls> for content scripts. After poking around your extension a bit I'd recommend removing content scripts from your manifest, replacing the <active_tab> permission with activeTab, and dynamically injecting content scripts with chrome.tabs.executeScript() when the user activates your context menu entry, browser action, or keyboard shortcut. This should significantly reduce how long SingleFileZ submissions are in review.

Simeon - @dotproto

Extensions Developer Advocate

[Gildas]

Thanks for your response.

I cannot remove any "broad host access" since the extension is supposed to save any webpage on the web/filesystem. The extension needs also to be able to save multiple tabs in one click. I already heavily optimized the injection of content scripts by concatenating them in the background script when the extension starts and injecting them with chrome.tabs.executeScript. Otherwise, it was way too slow. The ones you're seeing in the manifest are quite light and mandatory for the auto-save feature, and for example to retrieve fonts loaded with the FontFace API.

Basically, you're asking me to remove features from SingleFileZ because you cannot trust me as the publisher of SingleFileZ and nobody at Google really wants to review its code. I won't rewrite a special version of SingelFileZ for Chrome because I do not have the time to do so. Don't forget that some people write code for fun, not only to earn money with crapwares... The latter do not care about these restrictions because they earn money that allows them to support them.

Consequently, I'll remove all my extensions from the store soon and I'll recommend Chrome users to use Firefox if they want to use them.

[Simeon Vincent]

It seems I misunderstood SingleFileZ's feature-set when I wrote that suggestion. I thought it was only saving the current page on click or keyboard shortcut. I did not intend to suggest you remove features from your extension and I apologies for the confusion. 

Regarding your statement that "you cannot trust me as the publisher of SingleFileZ and nobody at Google really wants to review its code," review process is applied to all extensions regardless of publisher and we review the source of every extension periodically and on every publish. We don't have exceptions for individual publishers because history has shown us that any extension could fall victim to issues like compromised dependencies, malicious contributors, stolen accounts, etc.

For what it's worth, as a JSONViewer user I'll be sad to see your extensions go. I hope you'll consider continuing to support Chrome even if you don't publish your extensions to the web store.

Simeon - @dotproto

Extensions Developer Advocate

[Neea Rusch]

Hello Simeon

I have an extension that is used for downloading images. Images are hosted across various domains, and I download them in the background. I need XHR to fetch the image binary. I have tried other approaches such as using a canvas etc. but that does not work due to tainted canvas. TL;DR. I have no other way to achieve the desired behavior without requesting  "https://*/*", "http://*/*" permission that enables me to fetch the binary image data from multiple domains. I do not want to setup a proxy for this, since that will cause bottle necks and costs money to host and this is a free extension. 

I understand why you have restricted the usage of the said permissions, but having to wait for review even for internal beta versions is quite annoying to say the least. Can I at least request the internal beta to be whitelisted? I don't mind the production release to take a few days, my release schedule is much less frequent than that.

On Monday, July 1, 2019 at 1:38:53 PM UTC-4, Simeon Vincent wrote: