1386723 - There should be a way to deny webextensions some priveleges

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect)

Description

[Cam]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170731093534

Steps to reproduce:

Installed various addons for example 1Password


Actual results:

an item was added to the context menu


Expected results:

I should be able to prevent this without resorting to hiding it with userChrome.css

Comment 1

[Andrew Swan [:aswan]]

We could (with a non-trivial amount of both UX and engineering work) add a user interface to let you selectively remove permissions at install time, but I don't see how we could do this without breaking a lot of extensions.  Right now the documented behavior is that if and extension is installed that includes eg "contextMenus" in the manifest, then it will have access to the context menus apis.  If we let a user remove that permission, then existing code that calls browser.contextMenus.anything() will throw, and all sorts of things can and would break after that.

I think you're probably better off asking the extension author to provide you an option in the extension to disable the context menu entry.

Comment 2

[Cam]

And they told me to get lost, so I'm hoping Mozilla will implement this and then extension devs will have to respect it or their extensions will break just like you said and no-one will use them.

It'll self-correct and puts the power in the hands of the users.

Comment 3

[Andrew Swan [:aswan]]

I'm sympathetic but dropping a breaking change (both breaking compatibility between Firefox versions and breaking compatibility between Firefox and other browsers) onto extension authors is not the way to go about it.

Doing all the work this would entail will not force anybody to "have to respect it".  If a particular extension author is already unwilling to make their context menu entry optional, I find it hard to believe that they won't just refuse to support their extension if it is installed with any permissions withheld.

Comment 4

[Cam]

I dunno, I think it's more damaging for a company like AgileBits to let users go around saying their software doesn't work than to tell users that no you won't stop getting in their way and causing accidental clicks on your extension. After all accidental clicks are considered good engagement right? Grabbing users attention when they aren't already thinking about your sw and who cares if it makes them mad right? It's not like they have a choice in the matter.

Comment 7

[Mihai Dobrescu]

1. The users shuld be notified it would might break the extension.
2. Is Firefox meant to leak my data, after all? I don't see a reason to allow permissions an add-on would request, as long as that add-on wouldn't need them, but, malevolently, becomes a trap for the user in order to steal some private data and sell that to third parties without user's consent? This is the very definition of malware/spyware.
Assuming I use a font add-on in order to better design a web application, why that add-on would ask permission to access all my browsing data, that could be, for example, my gmail account or worse, my banking information? See this: https://support.mozilla.org/en-US/kb/permission-request-messages-firefox-extensions

"Access your data for all websites	The extension can read the content of any web page you visit as well as data you enter into those web pages, such as usernames and passwords.

Extensions requesting this permission might:

    Read product and price information from a page to help find you the best price on items you're shopping for
    Offer a password manager that reads and writes details of your username and password
    Provide an ad blocker by reading the content of each web page you open to find and remove ad code"

Is this Firefox's actual purpose, then?
Excuse me, but this is the above meaning.

Comment 8

[Mihai Dobrescu]

And, BTW, related to blocking some permissions, Android does that, the user grants permissions on request, the user could grantor deny some application's permissions at any time. And it's good.

Comment 9

[YF (Yang)]

(In reply to Andrew Swan [:aswan] (on PTO until 8/28) from comment #1)
> We could (with a non-trivial amount of both UX and engineering work) add a
> user interface to let you selectively remove permissions at install time,
> but I don't see how we could do this without breaking a lot of extensions. 
> Right now the documented behavior is that if and extension is installed that
> includes eg "contextMenus" in the manifest, then it will have access to the
> context menus apis.  If we let a user remove that permission, then existing
> code that calls browser.contextMenus.anything() will throw, and all sorts of
> things can and would break after that.

The deny feature can be completed with a specific minimum version or an allowable field, as well as AMO detection (addons-linter) and policy to pay attention. Any thinking?

Comment 10

[Andrew Swan [:aswan]]

I don't understand what you're suggesting

Comment 11

[YF (Yang)]

(In reply to Andrew Swan [:aswan] (on PTO until 8/28) from comment #10)
> I don't understand what you're suggesting

If you are concerned that this feature breaks the old webextensions, it can be only available when the extension declaration supports this feature and/or checking "strict_min_version", and AMO policy to recommends implementing it.

Comment 12

[Andrew Swan [:aswan]]

(In reply to YF (Yang) from comment #11)
> (In reply to Andrew Swan [:aswan] (on PTO until 8/28) from comment #10)
> > I don't understand what you're suggesting
> 
> If you are concerned that this feature breaks the old webextensions, it can
> be only available when the extension declaration supports this feature
> and/or checking "strict_min_version", and AMO policy to recommends
> implementing it.

In the category of solutions that require cooperation from extension authors, we already have optional permissions.  I don't see why we would build a new feature that amounts to a different way of doing the same thing.

Comment 13

[YF (Yang)]

(In reply to Andrew Swan [:aswan] (on PTO until 8/28) from comment #12)
> (In reply to YF (Yang) from comment #11)
> > (In reply to Andrew Swan [:aswan] (on PTO until 8/28) from comment #10)
> > > I don't understand what you're suggesting
> > 
> > If you are concerned that this feature breaks the old webextensions, it can
> > be only available when the extension declaration supports this feature
> > and/or checking "strict_min_version", and AMO policy to recommends
> > implementing it.
> 
> In the category of solutions that require cooperation from extension
> authors, we already have optional permissions.  I don't see why we would
> build a new feature that amounts to a different way of doing the same thing.

I think the optional permissions may be higher development costs and lower policy enforcement. Developers seems have to implement an options interface and operational instructions to implement the optional permissions, while deny permissions may only require declaration and fail detection, and support enforcement by AMO policy.