We need to stop automatically granting unknown api permission, by returning "invalid" for them here
https://searchfox.org/mozilla-central/rev/c0ca776/toolkit/components/extensions/Extension.jsm#143-158

This doesn't actually seem possible, afaics we never consult the raw manifest without normalization [1], which in turn strips out unknown permissions (that don't start with experiment. or look like host permissions), and logs a (an awful) warning:

Reading manifest: Error processing permissions.1: Value "speakFreely" must either: must either [must either [be one of ["clipboardRead", "clipboardWrite", "geolocation", "idle", "notifications"], be one of ["bookmarks"], be one of ["find"], be one of ["history"], be one of ["menus.overrideContext"], be one of ["search"], be one of ["topSites"], be one of ["browserSettings"], be one of ["activeTab", "tabs", "tabHide"], be one of ["cookies"], be one of ["webNavigation"], be one of ["downloads", "downloads.open"], or be one of ["webRequest", "webRequestBlocking"]], be one of ["alarms", "mozillaAddons", "storage", "unlimitedStorage"], be one of ["browsingData"], be one of ["captivePortal"], be one of ["devtools"], be one of ["identity"], be one of ["normandyAddonStudy"], be one of ["menus", "contextMenus"], be one of ["pkcs11"], be one of ["geckoProfiler"], be one of ["urlbar"], be one of ["sessions"], be one of ["contextualIdentities"], be one of ["dns"], be one of ["management"], be one of ["privacy"], be one of ["proxy"], be one of ["telemetry"], be one of ["nativeMessaging"], be one of ["theme"], or match the pattern /^experiments(.\w+)+$/], or must either [be one of ["<all_urls>"], must either [match the pattern /^(https?|wss?|file|ftp|*)://(*|*.[^/]+|[^/]+)/.$/, or match the pattern /^file:///.$/], or match the pattern /^resource://(*|*.[^/]+|[^/]+)/.*$|^about:/]

Feel free to reopen if you have an actual STR.

1. https://searchfox.org/mozilla-central/rev/f711552789/toolkit/components/extensions/Extension.jsm#688

STR (to simulate this bug):

1. Copy your Firefox application directory to a temporary location, e.g. from /usr/lib/firefox to /tmp/fxtemp.
2. Edit /tmp/fxtemp/omni.ja as rename the notifications permission to nutifications (one byte edit so that the permission is no longer supported; make sure that the file is edited in binary mode to not make other unrelated changes, e.g. with vim -b). The part of the file that you have to edit is the generated output of https://searchfox.org/mozilla-central/rev/da3f3eaaacb6fb344fd21ac29ace2da0e33f12d3/toolkit/components/extensions/schemas/manifest.json#370
3. Mark the directory as read-only, to prevent auto-update from updating the application: chmod -R -w /tmp/fxtemp
4. Create a new user profile, and start Firefox with it: mkdir /tmp/tmpprof; /tmp/fxtemp/firefox --no-remote -profile /tmp/tmpprof
5. Install https://addons.mozilla.org/en-US/firefox/addon/display-_anchors/
   -- note that the permission doorhanger does not contain any permission warnings.
   -- note that the global JS console also reports the message similar to comment 3.
6. Visit about:debugging, debug "This Nightly" and inspect the add-on. The error chrome.notifications is undefined should be shown. Clicking on the extension button should also trigger a similar error in the extension's console.
7. Quit Firefox.
8. Start the original Firefox application (where the notifications permission was supported): firefox --no-remote -profile /tmp/fxtemp
9. Click on the extension button, and observe that a desktop notification is shown.

Expected:

• Before step 8 successfully shows a notification, the user should be offered UI to consent to the "new" "notifications" permission, with the message "Display notifications to you" warning. E.g. by ignoring the permission until it is approved (doorhanger: new permission [approve] [cancel = disable add-on]).

Actual:

• At step 8, the add-on was able to use the "notifications" permission, while the user has not seen any permission warnings/prompts.

The fact that step 8 shows a desktop notification is a proof that updating a browser from a version that did not support the "notifications" permission to one that does

Note: If you want to simulate the bug while re-using the same application directory (e.g. if you run from source), then you can delete the startupCache/webext.sc.lz4 file instead (to force a recomputation of the permissions, instead of using the cached permissions).

(In reply to Rob Wu [:robwu] from comment #4)

Note: If you want to simulate the bug while re-using the same application directory (e.g. if you run from source), then you can delete the startupCache/webext.sc.lz4 file instead (to force a recomputation of the permissions, instead of using the cached permissions).

Hmm, this doesn't look like a normal situation that would happen to regular users. In normal operation, we shouldn't be re-parsing the manifest (and thus permissions) unless there is an update for the extension, at which point it would be detected as a new permission and prompted for.

Though I guess if someone actually manages to trigger the conditions similar to your STR, this is a potential issue.

I think the solution is to store static (manifest) permissions along with optional ones, and only base future decisions (like detection new permissions) on that.

I'm inclined to agree with comment 5, we should make use of the ExtensionPermissions store to track all permissions that are not runtime determined. With that, we'll also need to re-validate permissions when we reload them to ensure that privileged permissions cannot be written into the data store.