1308292 - (webext-permissions) [meta] (tracking) Webextensions required permissions handling

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P2)

Description

[Andrew Swan [:aswan]]

This is a tracking bug to cover the individual pieces needed to expose required webextension permissions (i.e., those in the "permissions" section of the manifest) to users when installing and upgrading webextensions.

Note that everything related to handling of optional permissions is tracked in a separate issue: bug 1197420

Comment 1

[Andrew Swan [:aswan]]

Removing bugs labeled blockers that are not necessary to enable permission prompts.  Follow up items related to required permissions can still be found by searching for webextensions bugs with "permissions" in the whiteboard.

Comment 2

[Andrew Swan [:aswan]]

Adding dev-doc-needed.  Developers don't have to take any explicit actions related to this bug, but I think it would be worth mentioning on the page that documents the manifest that some manifest declarations are exposed to users in permission prompts.

Comment 3

[Timvde]

Related: https://palant.de/2016/07/02/why-mozilla-shouldn-t-copy-chrome-s-permission-prompt-for-extensions

I'm not a UX expert, but I think the reasoning of the article is well thought out and should be taken into consideration. I personally don't have any strong feelings either way (my trust mostly lies in AMO's manual review process), I just wanted to represent the other side.

Comment 4

[Stephan Sokolow]

As a power user who does tech support for the rest of the family, I can also support the points given in the article.

Heck, even for my own use, I generally shy away from Chrome extensions because it's just too much bother to audit them myself.

That said, I'd see a permissions system that's as on-demand as possible paired with AMO's existing auditing as a step up for two reasons:

1. In places like F-Droid where I trust the source, I use the permissions readout as a second layer of security and, more importantly, as a way to weed out stuff from developers whose development methodology I don't agree with. (Primarily relating to the practice of speculatively asking for permissions you might want later or getting lazy about how broadly you allow your core functionality to apply.)

2. On-demand permission prompting (as with Geolocation or Android 6) is a great way to allow people to say "Yes, I want to do X, but I don't want you to have the extra permissions required by feature Y which I'll never use." (For example, not everyone who uses Video DownloadHelper uses the supplementary transcoding functionality.)

Comment 5

[Andrew Swan [:aswan]]

(In reply to Timvde from comment #3)
> I'm not a UX expert, but I think the reasoning of the article is well
> thought out and should be taken into consideration.

There was a discsussion about that post on the dev-addons mailing list last year that you can find in the archives.  The short summary is that nobody has suggested a concrete alternative to the current plan which leaves us with the choice of doing nothing or following the current plan.  We chose the second option, aware of its shortcomings but preferring those to the idea of not giving users any information.

(In reply to Stephan Sokolow from comment #4)
> That said, I'd see a permissions system that's as on-demand as possible
> paired with AMO's existing auditing as a step up for two reasons:

optional permissions (what you describe as on-demand) are slated to land in Firefox 54.

Comment 6

[Andy McKay]

All remaining bugs have been moved over to bug 1401643, since we think the core functionality is there.

Comment 7

[Will Bamberg [:wbamberg]]

I just saw this, since it got resolved :).

I think the request in comment 2 is already covered by the text in https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions:

"If you request permissions using this key, then the browser may inform the user at install time that the extension is requesting certain privileges, and ask them to confirm that they are happy to grant these privileges. The browser may also allow the user to inspect an extension's privileges after installation."

So I'm just marking this one dev-doc-complete. But let me know if we need anything else here.