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
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.
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.
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.
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.)
(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.