As identified by an add-on developer in <https://mail.mozilla.org/pipermail/dev-addons/2016-May/000610.html>, there are legitimate reasons for WebExtensions to be able to open URLs that correspond to certain about: URLs. There are arguments in Bug 1227462 about why this shouldn't be allowed in the general case. Because of the legitimate uses, however, we should allow add-ons to request special permission. There are three ways I can envision this being designed: 1) Expand the set of allowed operations granted by the "tabs" permission to include using tabs.create() and tabs.update() to navigate to all "about:" URLs. 2) Define a new permission (say, "aboutTabs") that explicitly grants this permission, separate from the other enhanced tabs permissions. 3) Expand host permission match patterns to include the "about:" scheme, and allow tabs.create() and tabs.update() to navigate to any URLs specified in the host permission match patterns.
Tagging Dan and Al for their awareness (since they were involved in Bug 1227462).
Do you have any concerns here, Dan? This seems reasonable.
Paul, the potential use case for security page permissions we discussed in a meeting.
I don't have a security concern about adding a permission to allow a WebExtension to load privileged pages. It can be a reasonable thing to do, and by adding the permission it flags the use for reviewers to check and make sure it _is_ reasonable. Doing something like this would be incompatible with Chrome and Edge though. might want to see if we can come up with something generic enough to pass muster with them.
(In reply to Daniel Veditz [:dveditz] from comment #4) > Doing something like this would be incompatible with Chrome and Edge though. > might want to see if we can come up with something generic enough to pass > muster with them. I was under the impression that our model was going to be "WebExtensions++", where we explicitly planned to add interfaces (and presumably permissions) above and beyond those supported by Chrome.
I have to confess I was struggling to keep up with the notes and the conversation on this issue as we got into some details in the meeting at London. So I'm going to try and summarize it and get it wrong, please correct me. This particular bug is about allowing about: pages to be created from tabs.create etc. In the sense that this about opening new tabs and windows this should be fine in that, as long as there is no escalation of privileges that allows a developer to escape the sandbox. In comment #4 dveditz suggests adding in a permission for this. I think the purpose of that permission is just to assist reviews and shouldn't be one we prompt users for.
FYI: Chrome extensions can navigate to *any* page, except for some explicitly blacklisted dangerous URLs (such as chrome://kill). This liberal approach has advantages and disadvantages: Advantages: - Extensions can activate protocol handlers which are unknown to the browser (e.g. magnet: URLs). - Extensions can provide a button to quickly access some internal page (Downloads, settings, ...) - like a glorified bookmark. - Extensions can guide the user to enable settings to allow the extension to function properly (see e.g. https://github.com/mozilla/pdf.js/pull/6233, the "chrome://extensions" "link" in the screenshot is using chrome.tabs.update because direct navigations are now allowed). Disadvantages: - If dangerous URLs are not blacklisted, then WebExtensions can cause bad things to happen. Being able to navigate to some URL in itself should not be dangerous, otherwise any site that can trick a user into copying and pasting a URL can cause harm. The current restrictions are blocking legitimate use cases, even data:-URLs (which are allowed in window.open()) are currently blocked!