Declaring compatible websites (without prompting the user)

[fregante]

Problem

The current optional host permission situation has a few inconsistencies and limitations across browsers. Here are some:

• Safari does not grant host_permissions on install
• "all sites" optional permissions are generally treated as an invite to enable the extension on "all sites" at once[^3]
• offering "optional content scripts" requires manually dealing with permission grants and content script registration[^4]

Proposal: "suggested hosts" and "available hosts"

These issues could be resolved with two additional well-defined top-level keys for the manifest. These two keys could replace (or be preferred to) host_permissions, optional_host_permissions and content_script.*.matches

suggested_hosts

• no permissions granted on install
• the browser will eventually prompt the user via badges (Firefox screenshot) and popups (Safari screenshot)
• the author can use permissions.request() and permissions.remove()

This is exactly how Safari currently treats host_permissions.

available_hosts

Like optional_host_permissions, but:

• the browser never prompts the user in any way
• the browser does not show a "enable on all sites" button/toggle

Example

This extension would show "No permissions requested" on install, then show a badge when the user visits YouTube. Optionally the user can enable the extension on any website that might be compatible.

{
    "name": "Watch History Collector",
    "description": "Tracks the titles of watched videos",
    "manifest_version": 3,
    "suggested_hosts": [
        "https://youtube.com",
        "https://vimeo.com",
    ],
    "available_hosts": [
        "*://*/*"
    ],
    "background": {
        "service_worker": "background.js"
    }
}

Follow-up for Safari

Safari does not support host_permissions the way it was defined, so they should mark the key as _"Not supported; aliased to suggested_hosts"_

[^3]: Safari shows an "Always Allow on Every Website…" button (screenshot); Firefox has a toggle (screenshot) that is a footgun (support requests) [^4]: Safari effectively allows this via plain content_script.*.matches='*://*/*, but the user is presented with "The extension wants to access this site" rather than "The extension is available for this site". My solution for this has been my webext-dynamic-content-script package. [^5]: Chrome has a (disabled) UI for this (screenshot); I wrote my own package too: webext-permission-toggle

[xeenon]

I think most browsers are on a path to do what Safari does today with host_permissions, so this new key might not be needed. I'm supportive though, if others think it is worth doing as a separate key.

[fregante]

I think most browsers are on a path to do what Safari does today with host_permissions

Chrome's first draft for MV3 intended to do that already[^3], but they changed their mind at some point. I'm not sure they want to revisit the default behavior just yet, probably not before MV4 anyway.

if others think it is worth doing as a separate key

If adding more "host" arrays is undesirable, these two behaviors could still be locked in via options. I want to reiterate that the problem here is specifically the lack of consistency and choice in how these permissions are presented to the user. Perhaps:

• grant_host_permissions: boolean - true by default; Safari only supports false

When set to false, this also withholds the permissions granted via content_scripts.*.matches and allows the removal via permissions.remove()

As for the second behavior, honestly I just wish Safari and Firefox stopped showing this button/toggle, because that's not what I mean when I specify optional_host_permissions: ["*://*/*"]:

If you want to keep them, then I'd love to see an option to hide it:

• propose_all_urls: boolean - true by default; not applicable to Chrome at the moment

[^3]: Quote from the document: _Since host permissions are going to require runtime approval by the user, they will not need a separate optional_host_permissions entry (whether such permissions will be removable via the permissions.remove API method is TBD.)_

[fregante]

Note that this set up would allow something really cool:

{
    "name": "Dark mode on demand",
    "manifest_version": 3,
    "grant_host_permissions": false,
    "propose_all_urls": false,
    "content_scripts": [{
        "matches": ["*://*/*"],
        "css": ["darkmode.css"]
    }]
}

Specifically:

1. no permissions requested on install[^1]
2. no prompting to enable the extension on specific sites (no badges, no popups)
3. host permission management UI provided by the browser[^2]
4. content script injection safely managed by the browser

The best part is that every browser already has this logic and UI built in, it's just not exposed evenly.

[^1]: [^2]: