Block extension from specific hosts

[fregante]

Problem

Extensions host permissions are not granular enough:

• if the extension requests "all sites" access (via manifest or permissions.request()), there's no way to remove specific websites¹
• if the permission is declared in the manifest (via host_permissions or content_scripts.*.matches), there's no way to withdraw it²

Proposal: permission block list

Browsers already have the ability to disable some hosts, but this information is not clearly exposed to the extension author nor can it be expanded.

await browser.permissions.getAll();
// => {origins: ['https://*/*']}

await browser.permissions.blocked.getAll();
// => ['https://banking.example.com/*', 'https://password-manager.example.org/*']

The extension could then ask for removal: browser.permissions.blocked.remove(['https://banking.example.com/*'])

• If the block was added via browser UI, the user will be prompted: "The extension requests access to banking.example.com"
• If the block was added via browser.permissions.blocked.add, the action will proceed automatically.

This ability could also be used by the extension author to enable/disable its own content scripts and user scripts as necessary, for example to:

• "Disable extension on this domain"
• "Reload without extension"
• "Disable extension for 15 minutes"

Related

This was proposed in some form in #653, but this proposal applies to permissions more generically. Adding a website to the block list would also disable the injection of its content scripts.

#700 also has some overlap in capability, but intent and possibilities are very different.

Footnotes

1. Safari can do so via browser UI (screenshot), but not via API ↩

2. Safari and Chrome can do so via browser UI (screenshot), but not via API ↩

[carlosjeurissen]

Related to the disallow_host_permissions proposal: #123. Which is a static equivalent of this proposal. What is the motivation to do it dynamically? Content scripts for example allow excludeMatches and excludeGlobs.

[fregante]

Static configuration is for choices made by authors; APIs are for choices made by the user. I also gave some examples:

This ability could also be used by the extension author to enable/disable its own content scripts and user scripts as necessary, for example to:

• "Disable extension on this domain"
• "Reload without extension"
• "Disable extension for 15 minutes"

[rustyzone]

Really like this idea had been drafting something similar a while back ( https://gist.github.com/rustyzone/16771562bb512d70354c5a9e7e3b88c0 )

Main difference here was not being extension specific particularly for cases like the banking example.

[rdcronin]

Thanks for writing this up! This was discussed at the WECG meet-up.

There's a few different pieces here. In general, I think most browsers are opposed to having the extension settings incorporate the user permission settings. However, we're very supportive of extensions proactively limiting their own set of permissions ("I never want to run on site ").

We think this is generally captured, in principle, by issue #123, which proposes the static disallow_host_permissions key. There is an important distinction there, which is that this proposes API integration to allow dynamically configuring that set. We're supportive of this, as well -- there's lots of extensions that want to "turn themselves off" on different sites.

Given that, I'm going to merge this into issue #123 and add a note there about being modifiable at runtime. Please feel free to continue the discussion there.