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¹
• offering "optional content scripts" requires manually dealing with permission grants and content script registration²

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"

Footnotes

1. Safari shows an "Always Allow on Every Website…" button (screenshot); Firefox has a toggle (screenshot) that is a footgun (support requests) ↩

2. 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. ↩

[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¹, 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

Footnotes

1. 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¹
2. no prompting to enable the extension on specific sites (no badges, no popups)
3. host permission management UI provided by the browser²
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.

Footnotes

1. ↩
2. ↩

[fregante]

@xeenon I'm getting reports from Safari 15.4 users being prompted to enable my extension (with optional_host_permissions) multiple times on any website. This is exactly the sort of pattern that this proposal aimed to avoid.

• Extension asks to access other websites in Safari 15.4 refined-github/refined-github#8319

[rdcronin]

Thank you for filing the issue! I definitely see the pain point here, and we discussed this at the WECG meet-up.

However, in Chrome, we're opposed to this change, largely for the reason that @xeenon highlighted here. These keys seem to be trying to deal with the fact that browsers present permissions in different ways, but the way in which browsers present this UI is outside the scope of the WECG (and is likely to change).

Additionally, in Chrome, we want to move to a world where no host permissions are granted at install time (similar to what Safari is doing now, and what we had originally planned out in MV3). In that world, there wouldn't be a difference between host_permissions and suggested_hosts -- we wouldn't allow granting hosts at install time, so all hosts would essentially be treated the same.

On another note is that we recently introduced permissions.addHostAccessRequest, which allows extensions to programmatically trigger a slightly-more-visible prompt to the user. That may help with a few of these cases.

Firefox and Safari also indicated their opposition to these keys, but I'll let those vendors add their own labels.