Proposal: stop adding `host_permissions` from `content_scripts`

[carlosjeurissen]

Currently when using specific matches in content_scripts, they will be added to the list of host_permissions the extension requests / has access to (in some cases, only when granted).

My proposal is to stop this behavior and require devs to define this in either host_permissions, optional_permissions or permissions. This would align it with other APIs like the webRequest API. In addition to aligning it with other APIs, there are two more reasons for this change:

1. Some host_permissions you only want to apply in specific cases. So the content_scripts will only be applied when the host_permissions are granted. This makes sure not all host_permissions are required to be granted right from the install of the extension.

2. When having multiple content_scripts and matches, you will end up polluting the host_permissions. Say you have matches like these: "https://example.com/*something=true*", "https://example.com/*something=false*", "https://example.com/*test=true*". All of them will be added to the host_permissions causing conflicts with granting / removing permissions for specific domains. Easy solution here would just be to add https://example.com/* to the permissions.

Due to the backward compatibility issues, this may only be doable for manifest v4.

[xPaw]

I just ran into this issue where I wanted to support a new domain my extension, I added it to optional_host_permissions, and then listed new urls in the content scripts. Upon extension update it disabled the addon in Chrome because the matches of content scripts are in fact not optional.

So either the fix here is this issue, or adding something like optional_matches to content_scripts.

SteamDatabase/BrowserExtension@eba3f65#diff-ffa5b716b5a57837f7929dfcca4b4dfdeb97210a7fd5a12d2f1978846d6f1743

[fregante]

It helps to clarify what the current situation is exactly.

• injecting content scripts effectively gives access to the specific host and all of its contents
• in some browsers, having a host in matches but not in host_permission puts the extension in a limbo where it has access to everything, but it's not reported in permissions.getAll() (if I remember correctly)

What is it that an extension with "matches": ["https://example.com/*"] should or shouldn't be able to do?

[xPaw]

I believed that hosts had to be listed in host_permissions for them to work in content scripts, but that clearly is not the case.

This also explains why I have a *.example.com host permission, but content scripts list specific subdomains which makes Firefox list these subdomains in permissions specifically.

[fregante]

@carlosjeurissen Re-reading this, it sounds like you want this extension to not inject any content scripts because it has no host_permissions:

{
  "manifest_version": 4,
  "host_permissions": [],
  "content_scripts": [{
    "scripts": ["main.js"],
    "matches": ["https://example.org/*"]
  }]
}

Is that correct? If so, I most definitely want it (it's an alternative solution to #700)

[carlosjeurissen]

@fregante Exactly. Considering the PR on permissions update behaviour:
#798

In a similar fashion, we can add a key under "permissions_behavior" stating how host permissions should be handled in content scripts. This would mean we can offer this functionality without requiring a new manifest version.

Imagine the following manifest:

{
  "manifest_version": 3,
  "host_permissions": [],
  "content_scripts": [{
    "scripts": ["main.js"],
    "matches": ["https://example.org/*"]
  }],
  "permissions_behavior": {
    "content_scripts": "suppress"
  }
}

permissions_behavior.content_scripts would be set to keywords giving greater flexibility with current values "suppress" meaning not automatically prompt the user, and "prompt", which suggests browsers to prompt these permissions when they please.

On another note, we could also use permissions_behavior to allow developers to instruct the browser to not prompt permissions in the host_permissions or optional_host_permissions.

As for the content_scripts, allowing the permissions to not be automatically granted gives greater flexibility to developers and reduces code complexity with developers having to deal with registering content scripts dynamically instead of declaratively.

[carlosjeurissen]

in some browsers, having a host in matches but not in host_permission puts the extension in a limbo where it has access to everything, but it's not reported in permissions.getAll() (if I remember correctly)

@fregante do you have a source for this?

As for #700, feel free to mark it as closed as duplicate for this issue (116).

[fregante]

@fregante do you have a source for this?

Here you can see an extension with content_scripts for example.com that still acts like it doesn't have permission to it when using the permissions.request() API:

demo extension, 3 files

{
  "manifest_version": 3,
  "name": "Limbo Hosts",
  "version": "1.0",
  "optional_host_permissions": ["*://*.example.com/*"],
  "background": {
    "service_worker": "background.js"
  },
  "action": {
    "default_title": "Click to request permissions"
  },
  "content_scripts": [
    {
      "matches": ["*://*.example.com/*"],
      "js": ["content.js"]
    }
  ]
}

console.log('Content script loaded on example.com');

chrome.action.onClicked.addListener(async () => {
  try {
    await chrome.permissions.request({
      origins: ['*://*.example.com/*']
    });
    console.log('Permissions granted for example.com');
  } catch (error) {
    console.log('Permission request failed:', error);
  }
});

Other inconsistencies:

• await chrome.permissions.getAll() returns {origins: ['*://*.example.com/*']}
• tabs.query() doesn't return the tab's URL
• the browser prompts the user for access to example.com on install

This is why they're in "limbo". It has permission but it really does not.

feel free to mark it as closed as duplicate for this issue

Not exactly a duplicate, it's a different solution for the specific issue I had: declaring content script support "for all" but injecting only after the user grants access to certain hosts:

{
  "manifest_version": 3,
  "optional_host_permissions": ["*://*/*"],
  "content_scripts": [{
    "scripts": ["main.js"],
    "matches": ["*://*/*"]
  }]
}