Clarification about the activeTab and tabs permissions

[Theme Wise]

A couple of days ago I published an extension that has been in Pending Review status since, due to "board host permissions". I've been wondering what permissions might have triggered the need for such a review.

 

For the functionality of my extension (detemining if a website uses WordPress, Shopify, etc. and set the icon for the the browser action accordingly), I need to access every website the user visits. For that reason, I've required the following permissions in the manifest:

activeTab
tabs
http://*/*
https://*/*

I realize now that my extension works just fine with just tabs. I've tried to just require activeTab, because according to this doc, it temporarily grants the tabs permission temporarily but, sadly, it's not enough.

I also realize that the content scripts already match those two patterns, so seems redundant to require them again in permissions.

My questions:

• Does it make sense to require activeTab when you're already requiring tabs?
  
• Does it make sense to add http://*/* and https://*/* in permissions when the content scripts already match those two match patterns?
  
• If modify the manifest to only require tabs and then reupload the extension, will it get published without the "broad host permissions" notice and without requiring a review? Or will it just put me at the end of the queue again?
  

The extension ID is ehfnfeikdcfkbjfhfoeahafbigichaio.

Thanks!

[Theme Wise]

To anyone wondering, I just tried only requiring the "tabs" permission in the manifest, reuploading and publishing and I still got the "broad host permissions"/Pending Review notice 🙄

[馮韋元Francois Devatine]

Hello,

I don't think it is needed to require activeTab when you already require tabs, since tabs give you even more

I think that if you require a domain in content scripts, permissions-wise it is the same as if you required it in the permissions. Upon install the user will see the same permission requirement in the popup

You can take a look at this document I found a while ago, I think this is being implemented right now and that's the reason for a lot of people getting a manual review pending: https://blog.chromium.org/2018/10/trustworthy-chrome-extensions-by-default.html (check Changes to the extensions review process part).

I believe a lot of people are currently waiting because it is a new kind of process on the chrome store team. Hopefully they will catch up with all the reviews soon.

Regards,

Francois

--
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 post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/cac4fb90-4fb9-4acc-8645-aaa53ba9643c%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[genesis96839]

Was it published after pending review? Or did you make any changes after the first pending review?

I'm stuck in the same scenario..

[Theme Wise]

Hi Francois,

thanks for the detailed answer!

You're correct that I was requiring redundant permissions.

What I ended up doing, as per feedback of the support team and that blog post is using "optional permissions". Now I only require activeTab and then I have a disclaimer in which I ask the user for hosts permissions. It feels cleaner this way and it was published without the need for a review, win-win.

Anyways, thanks again!

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

[Theme Wise]

@genesis96839

Like I told Francois, what I did was a whole refactor in which I use "optional permissions" to require for host access in the UI. The user then decides whether he wants the extension to run on every website (which I encourage), or not.

After doing this, I didn't need a compliance review to publish the extension.

Here's the link to the extension, if you want to see how I did it and give some feedback perhaps 🙂

Anyways, I guess it's down to the requirements of your extension. I'm still not 100% convinced by this approach, but I will test it out.

[genesis96839]

Got it. Thanks mate.

But did you cancel the pending review extension and resubmit again or just added an update to that pending review extension?

[Theme Wise]

I had to cancel the pending review to be able to edit anything at all. Then I uploaded the new version, and sumbitted it for publishing.
After around 5 minutes the extension was publicly available.

[sim...@chromium.org]

Hey all,

It looks like there’s some confusion about what exactly the activeTab and tabs permissions do. Despite their similar names they fill rather different roles.

• The tabs permission gives the extension access to potentially sensitive data about browser tabs: specifically the tab’s url, title, and favIconUrl properties on the Tab object. This permission is NOT required to use the rest of the chrome.tabs API.

• The activeTab permission gives the extension temporary access to a tab as if the extension had specified the host and tabs in the permissions section of the manifest. Access will be revoked when the user navigates away from the current granted origin.

Going back to Theme Wise’s original questions…

Q: “Does it make sense to require activeTab when you're already requiring tabs?”

A: Maybe! If you need access to all tab URLs (e.g. a tab manager extension) AND need access to arbitrary hosts (e.g. a text replacement extension) then using both makes sense. That said, we recommend extension authors request the minimum set of permissions required for their use case.

Q: “Does it make sense to add http://*/* and https://*/* in permissions when the content scripts already match those two match patterns?”

A: Maybe! The roles of background and content scripts are rather different, so it depends. Both content scripts and background pages may need those patterns depending on what you’re trying to do.

As a quick refresher, match patterns in the manifest’s permissions array give the background page access to APIs like chrome.webRequest, chrome.cookies, and chrome.tabs.executeScript(). Content scripts defined in the manifest’s content_scripts object have a matches array that specifies where that script will run. These scripts behave like other scripts included by the page’s author but with a couple special APIs and the ability to communicate with the background page.

If your extension is structured such that the content script can provide the background page with the data it needs so the extension can avoid requesting host permissions, that’s strictly better than asking for more than you need. Again, we advise using the minimum, most restricted set of permissions you can.

Q: “If modify the manifest to only require tabs and then reupload the extension, will it get published without the "broad host permissions" notice and without requiring a review? Or will it just put me at the end of the queue again?”

A: If you’ve updated your manifest’s permissions to only request tabs but have content scripts that run on http://*/* and https://*/* you’ll still get dinged for broad permissions. Generally speaking, the broader set of capabilities an extensions requests, the stricter, more thorough the review process.

Hope that helps clear things up a bit.

Simeon

Chrome Developer Advocate

[Theme Wise]

Hi Simeon,

thank you very much for the very detailed answer. It really cleared up things for me and in retrospect, it makes a lot of sense.

I ended up only requiring activeTab permissions, and http://*/*, https://*/* optional permissions, which allowed me to publish the extension without a review.

The only thing that I realize is that during the refactor I removed the content_scripts from the manifest, and did chrome.tab.executeScript to run it instead. I don't really use chrome.webRequest, nor chrome.cookies right now, but I might in the future (the purpose of my extension is to identify technologies in websites, like Wappalyzer, so I will probably need to process web requests and cookies to fingerprint some of them), so I guess is not that big of a deal.

Anyways, if anyone is interested here's the end result: https://chrome.google.com/webstore/detail/theme-wise-identify-front/ehfnfeikdcfkbjfhfoeahafbigichaio.

Thanks again!