1392342 - Provide a way to disable add-ons on specific domains according to user's request

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, enhancement, P5)

Description

[Alice0775 White]

For security and privacy reason, I want to disable add-ons on specific domain(such as Bank).

Comment 1

[:Gijs (he/him)]

This would need webextensions work, first of all.

How disabled would things be? Would they, for instance, still be able to read tab titles/urls if they could do that in the normal case? Or should Firefox be pretending those tabs don't exist, or just don't give them correct URLs or titles? I'm trying to figure out how this would work, but it's not 100% clear to me.

Comment 2

[Alice0775 White]

When a addon requests them from API, simply return null/fail when domains match
1. DOM access(all the time)
2. password and cookie DB(all the time)
3. keyboard stroke(if the domain page is foreground)
4. screencapture (if the domain page is foreground)
5. http request(all the time)
6. title and url(all the time)

I think the following is quite difficult / impossible, but
7. clipboard(if the domain page is foreground. And even if it is background)
8. history and bookmarks DB(all the time)

Of course, the Legacy add-on has more privilege than Web-ext.
However, I hear that Chrome's addon often change to Malware through automatic update system.
I am afraid.

Comment 3

[Kris Maglione [:kmag]]

(In reply to :Gijs from comment #1)
> This would need webextensions work, first of all.
> 
> How disabled would things be? Would they, for instance, still be able to
> read tab titles/urls if they could do that in the normal case? Or should
> Firefox be pretending those tabs don't exist, or just don't give them
> correct URLs or titles? I'm trying to figure out how this would work, but
> it's not 100% clear to me.

We could probably implement most of this by adding an origin blacklist to complement our origin whitelist. In theory, that should probably cover pretty much everything, since no APIs are supposed to give add-ons access to origins they don't have permissions for. The activeTab permission might be a sticking point, though. And probably things like captureVisibleTab(), which are tied directly to the <all_urls> permission rather than to specific domain permissions.

Comment 4

[Caitlin Neiman [:caitmuenster]]

Hi Alice0775, this has been added to the agenda for the WebExtensions APIs triage meeting on September 26. Would you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Agenda: https://docs.google.com/document/d/1pw5y-GHwDLPV9bYK4HWCiZtslqFtAeL3G9bC4ZDbdjs/edit#

Comment 5

[Andy McKay]

There's a few problems that we discussed with this plan. It might be hard to explain to end users, it certainly seems like a power user feature. There's also a concern that it will permeate every API decision we make from now on. The idea that some add-ons might work in some cases, but not in others would be a tough thing for developers to manage as well.

Things we'd rather support are the things we are planning on working on, or already exist in Firefox. Supporting better private browsing mode, which would allow you to pick and choose the add-ons that work in private browsing mode. Container support and supporting what extensions work in what container. Given all the other UI artifacts going into those modes, that seems a better way to go.

Comment 6

[Kris Maglione [:kmag]]

Closing all open bugs with the [design-decision-denied] whiteboard flag.