w3c / w3c/webextensions

Proposal: stop adding `host_permissions` from `content_scripts`

Open
#116 10 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement needs-triage: chrome needs-triage: firefox supportive: safari
Dominant language
Bikeshed
Stars
711
Forks
95
Avg merge
10d 11h
Merged PRs (30d)
2

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing how content_scripts currently affect host_permissions, then compare the proposed explicit use of host_permissions, optional_permissions, or permissions. Consider the manifest v4 compatibility constraint and the backward-compatibility discussion. Done means the specification defines the changed permission behavior and its compatibility implications.

Written by the indexing model from the issue text.

Assessment

Domain
authorization, documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.