Adam Roach [:abr] Reporter
	Description • 8 years ago

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.

	Adam Roach [:abr] Reporter
	Comment 1 • 8 years ago

Tagging Dan and Al for their awareness (since they were involved in Bug 1227462).

	Al Billings [:abillings - ex-MoCo]
	Comment 2 • 8 years ago

Do you have any concerns here, Dan? This seems reasonable.

	Al Billings [:abillings - ex-MoCo]
	Comment 3 • 8 years ago

Paul, the potential use case for security page permissions we discussed in a meeting.

	Daniel Veditz [:dveditz]
	Comment 4 • 8 years ago

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.

	Adam Roach [:abr] Reporter
	Comment 5 • 8 years ago

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

	Andy McKay
	Comment 6 • 8 years ago

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.

	Rob Wu [:robwu]
	Comment 7 • 8 years ago

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!

	mozilla.utensil
	Comment 11 • 7 years ago

Any status on this? We need to open about:addons to fully migrate to webextensions...
thanks

	Rob Wu [:robwu]
	Comment 12 • 7 years ago

(In reply to mozilla.utensil from comment #11)
> Any status on this? We need to open about:addons to fully migrate to
> webextensions...

If your add-on has an inline options page, then you can open about:addons (with your extension's options page shown) using browser.runtime.openOptionsPage:

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/openOptionsPage

	mozilla.utensil
	Comment 13 • 7 years ago

Thanks for the quick reply, but I don't think that does what I want. I need to open the about:addons page that shows all the addons installed, as openings chrome://extensions does. Using browser.runtime.openOptionsPage() as you suggest instead opens two new tabs for me, about:addons showing only my addon, and the inline options page...

	mozilla.utensil
	Comment 14 • 7 years ago

Any other thoughts, or a status update? Is this in the works? thanks

	Andrew Swan [:aswan]
	Comment 17 • 7 years ago

I'm trying to wrap my head around this, I think there are several things that come up around loading urls:

1. When opening a URL in an existing tab, the XSS attack described in bug 1227462
2. Opening a new window/tab with window.open() provides the caller with the destination window object if they have the same origin
3. Some about: pages may not be prepared to handle arbitrary user input in query parameters (eg what if you open about:reader?url=javascript:whatever)

Due to #1, we check any urls that an extension tries to load with browser.tabs.create() (which opens a new tab) or browser.tabs.update() (which can cause an existing tab to load a new url) with nsIScriptSecurityManager.checkLoadURIWithPrincipal().  This is the only reason I bring up #2 since I think window.open() ends up in the same place (probably with different flags?) to check a URL passed to it.  However, I don't think #2 is actually an issue here since extension pages are not same-origin with about: pages.

As for #3, it looks like we have (or had?  or partially had?) a concept of which about: pages can be safely linked to:
http://searchfox.org/mozilla-central/rev/40e8eb46609dcb8780764774ec550afff1eed3a5/docshell/base/nsAboutRedirector.cpp#28-30
But empirically, that comment doesn't appear to be true any more, "buildconfig" has the URI_SAFE_FOR_UNTRUSTED_CONTENT flag but when I try to link to it I see a Security Error in the browser console.

I'm way over my head in arcane platform stuff here.  Boris, is the above correct and complete?  The quick context is that there are situations where extension want to open or navigate to about: pages.  UX concerns aside, are there reasons I've overlooked why this would be unsafe?  If we can agree this is safe for at least a subset of about: pages, how do we get there from here?

	Boris Zbarsky [:bzbarsky]
	Comment 18 • 7 years ago

My first question is actually what the initial motivating use case is.  The link in comment 0 seems to go to a thread that has nothing to do with this bug.

> 1. When opening a URL in an existing tab, the XSS attack described in bug 1227462

This could be addressed without doing a general checkLoadURI check, fwiw.  Or by comparing checkLoadURI with/without DISALLOW_INHERIT_PRINCIPAL and disallowing only if the two disagree.

> 3. Some about: pages may not be prepared to handle arbitrary user input in query parameters

Right.  This comes back to the last paragraph of comment 7, where the "should not be dangerous" is definitely aspirational but likely false in practice in various cases.  Which is why the entire CheckLoadURI mechanism exists, in fact.

> "buildconfig" has the URI_SAFE_FOR_UNTRUSTED_CONTENT flag but when I try to link to it I see a
> Security Error in the browser console.

There are two separate concepts at this point:

1)  URI_SAFE_FOR_UNTRUSTED_CONTENT (not very well-named anymore): If set, the about: URI will _not_ run as system.

2)  MAKE_LINKABLE: whether untrusted content can link to the URI in question, but only if URI_SAFE_FOR_UNTRUSTED_CONTENT is also set.  This is incorrectly referred to as "URI_CONTENT_LINKABLE" in the docs for URI_SAFE_FOR_UNTRUSTED_CONTENT... :(

Obviously the issue in this bug is all about about: pages that currently are _not_ listed as "can be safely linked to"; that's the whole problem, right?

> Boris, is the above correct and complete?

Sort of.  In general, this should be a problem exactly in the sense that XSS is a problem.  With that in mind...

1)  It's not clear to me why the thing described in bug 1227462 is a problem.  It's not a problem on the web.  Are we doing those loads with a triggering principal that doesn't correspond to the relevant extension (e.g. system principal), or something?  If so, _that_ seems like something we should fix in general, no?

2)  Things like "you get access to the window you opened" are not an issue per se, in the sense that this happens on the web too.

3)  The fundamental premise of this bug (that about: URIs are "semi-privileged") is false.  The only actual URI mentioned in this bug as something extensions want to load is about:addons, which is system-privileged.

4)  The real problem is that this _is_ an XSS problem.  On the web, the responsibility for hardening against XSS injection attacks of various sorts basically falls on the target site.  The browser prevents direct scripting, but if the attacker can inject content of their choice into your site, that's your problem.  We do provide some tools like CSP to help avoid this problem, of course.  In the context of about: pages, we have historically had an additional mitigation that the web at large does not have: we simply prevent arbitrary loads of the about: page from untrusted content.  This reduces the XSS attack surface quite significantly, and allows us to not have to deal with carefully auditing all the bits of those about: pages.  Which we have not done, by the way.

Additionally, the consequences of a successful XSS attack on a privileged about: page are significantly more severe than the consequences of a successful XSS attack on a random site: the former gets you full local code execution.

OK, so what do we actually do?  We could add some sort of "linkable from extensions" flag to some subset of about: URIs (Which ones?  See my question above.) and then allow all extensions, or extensions with certain permissions, to link to those.  We would need to audit those about: URIs carefully to make sure they have no XSS vulnerabilities.  Doubly so if they're not URI_SAFE_FOR_UNTRUSTED_CONTENT.

But in general, I'm not a huge fan of this for two reasons.  First, which things are about: vs chrome:// is a pretty arbitrary distinction.  Why do extensions need to open about: URIs but not chrome:// URIs?  Or do they need to open the latter too?  Second, the fact that an about: URI is how one gets to some functionality is totally an implementation detail that we may want to change.  about:preferences used to not exist, and may stop existing again.  about:addons may stop existing.  We don't really want extensions to depend on these implementation details if we can avoid it, in my opinion; it would be better if we found out what their actual use cases are and added explicit APIs for those.

	Boris Zbarsky [:bzbarsky]
	Comment 19 • 7 years ago

Maybe the link in comment 0 was supposed to be to https://mail.mozilla.org/pipermail/dev-addons/2016-May/000609.html

If so, that's talking about loading about:reader, which is at least URI_SAFE_FOR_UNTRUSTED_CONTENT.  I would be OK with making it linkable from all extensions (and probably doing the same for all URI_SAFE_FOR_UNTRUSTED_CONTENT) about: URLs.  That does not solve the about:addons problem, of course.  Also, the approach suggested in that mail presupposes that the way one loads reader mode is by loading "about:reader?url=stuff", which is relying on an internal implementation detail of reader mode that may be subject to change, as I noted above.

	mrmr1993
	Comment 20 • 7 years ago

> We don't really want extensions to depend on these implementation details if we can avoid it, in my opinion; it would be better if we found out what their actual use cases are and added explicit APIs for those.

For Vimium-ff, we have our own address/search bar. This has worked fine on Chrome for years, even on privileged URLs, but we keep getting user reports that about:addons, etc. and bookmarklets (javascript:...) don't work in Firefox. As nice as it is to have APIs for everything, it's frustrating for us and the users that we can't open URLs they've specifically requested.

	Ed
	Comment 21 • 7 years ago

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #18)
> My first question is actually what the initial motivating use case is.  The
> link in comment 0 seems to go to a thread that has nothing to do with this
> bug.

I believe https://bugzilla.mozilla.org/show_bug.cgi?id=1356251 is the motivating case.

	Boris Zbarsky [:bzbarsky]
	Comment 22 • 7 years ago

mrmr1993, thank you.  That is useful information.  I don't understand why the decision was made to block javascript: offhand, actually.

Ed, thank you as well.  That is a useful usecase to keep in mind.

Note that both of these use cases would be addressed by allowing load of bare "about:foo" URIs without query parameters, which would mitigate XSS concerns, but not address the "about:reader?url=stuff" usecase mentioned above....

	Kris Maglione [:kmag]
	Comment 23 • 7 years ago

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #18)
> 1)  It's not clear to me why the thing described in bug 1227462 is a
> problem.  It's not a problem on the web.  Are we doing those loads with a
> triggering principal that doesn't correspond to the relevant extension (e.g.
> system principal), or something?  If so, _that_ seems like something we
> should fix in general, no?

At the time, data: URIs inherited principals, so if they were loaded into a tab
with an existing page loaded, they would inherit that principal. We could have
allowed the load and disabled principal inheritance instead, but the semantics
would have gotten pretty muddy.

At this point, we really just need to use the appropriate triggering principal
for the load, and make sure that that's the principal that gets inherited.

> 3)  The fundamental premise of this bug (that about: URIs are
> "semi-privileged") is false.  The only actual URI mentioned in this bug as
> something extensions want to load is about:addons, which is
> system-privileged.

Dan's original use case was view-source: URIs, which have weird semantics, and I
was considering semi-privileged.

> 4)  The real problem is that this _is_ an XSS problem.  On the web, the
> responsibility for hardening against XSS injection attacks of various sorts
> basically falls on the target site.  The browser prevents direct scripting,
> but if the attacker can inject content of their choice into your site,
> that's your problem.  We do provide some tools like CSP to help avoid this
> problem, of course.  In the context of about: pages, we have historically
> had an additional mitigation that the web at large does not have: we simply
> prevent arbitrary loads of the about: page from untrusted content.  This
> reduces the XSS attack surface quite significantly, and allows us to not
> have to deal with carefully auditing all the bits of those about: pages. 
> Which we have not done, by the way.
> 
> Additionally, the consequences of a successful XSS attack on a privileged
> about: page are significantly more severe than the consequences of a
> successful XSS attack on a random site: the former gets you full local code
> execution.

We also have a long history of assuming that, since arbitrary web content can't
load privileged URLs, the data in their query/hash parameters can be trusted. I
don't want to make any bets that there aren't any places where we don't sanitize
that data, or take actions based on it. There have definitely been exploits of
extension URLs that take action based on their query parameters in the past.

> OK, so what do we actually do?  We could add some sort of "linkable from

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #22)
> mrmr1993, thank you.  That is useful information.  I don't understand why
> the decision was made to block javascript: offhand, actually.

Because javascript: URLs inherit the principal of the page they're loaded into,
which the extension may not have permission for. And if we load with principal
inheritance disabled, there's not much point in loading javascript: URLs at all.

	Boris Zbarsky [:bzbarsky]
	Comment 24 • 7 years ago

> so if they were loaded into a tab with an existing page loaded, they would inherit that principal.

Only if the caller either passed system as triggering principal or passed no triggering principal.  Either behavior would be a bug in the caller, in my opinion....

> we really just need to use the appropriate triggering principal for the load, and make
> sure that that's the principal that gets inherited.

Yes, agreed!

> Dan's original use case was view-source: URIs

OK, that's not what comment 0 is about, and this is the first mention of view-source: in this bug.  ;)

I think there should be no issue at all with allowing webextensions to load view-source: urls.

> We also have a long history of assuming that, since arbitrary web content can't
> load privileged URLs, the data in their query/hash parameters can be trusted. 

Right, exactly.

> Because javascript: URLs inherit the principal of the page they're loaded into,

Again, only if there is no triggering principal passed, right?  If there's a triggering principal passed they inherit that, and just don't run if that doesn't subsume the principal of the page they're being loaded into.

This is just like the data: issue: it "simply" requires getting the triggering principal right.

	Andrew Swan [:aswan]
	Comment 25 • 7 years ago

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #24)
> OK, that's not what comment 0 is about, and this is the first mention of
> view-source: in this bug.  ;)
> 
> I think there should be no issue at all with allowing webextensions to load
> view-source: urls.

Those got handled separately in bug 1261289.  The patch there did in fact add a URI_LOADABLE_BY_EXTENSIONS flag, though that flag applies to protocol handlers, not about: modules so its not directly useful here.

From comment 22, do I understand that you believe it would be safe to allow extensions to open "bare" about: urls (ie no query string and perhaps no hash reference?)  Or that would only be safe after marking individual about modules safe based on an audit?

Note that we've already done separate work to handle the specific about:reader case in bug 1408993 and we can do additional similar features if necessary, but at least for the simple cases the vimium use case seems compelling and like something we ought to be able to handle...

	Adam Roach [:abr] Reporter
	Comment 26 • 7 years ago

bz -- you tagged me with ni?, but I don't see a question directed at me here. What information would you like me to provide?

	Colin Caine
	Comment 27 • 7 years ago

> which about URIs?

Hopefully all of them!

But these are most important: addons, downloads, config, debugging, robots

---

The motivation is mostly from add-ons that wish to provide an alternative UI to firefox, generally something inspired by Vim (Vimium, vimperator, vim-fx).

It's important for vim-like-UIs' UX that users can do everything they want to from the UI we implement. If users have to fall-back to a UI that they've deliberately tried to replace or augment, that's confusing.

:aswan's suggestion would suit this use-case reasonably well (users won't be able to paste in about: URIs with get parameters, but I've never had cause to do that).

There are similar bugs that the same reasons apply to for most of the classes of URI that firefox forbids webextensions to set tabs to:

about: here
file: Bug 1266960
data: Bug 1317166 (can already open data URLs with window.location.href from content scripts)
chrome: no bug yet

	Boris Zbarsky [:bzbarsky]
	Comment 28 • 7 years ago

> but I don't see a question directed at me here.

The question was what the link in comment 0 was supposed to be, because the link actually there has nothing to do with this bug.

	Boris Zbarsky [:bzbarsky]
	Comment 29 • 7 years ago

> do I understand that you believe it would be safe to allow extensions to open "bare" about: urls
> (ie no query string and perhaps no hash reference?) 

I believe it would be easier to prove it safe than it would be to prove arbitrary parameters safe.  We would still need to audit some to make sure it's OK.

Since we have a URI_LOADABLE_BY_EXTENSIONS mechanism already, by the way, we could reuse it here.  nsAboutProtocolHandler implements nsIProtocolHandlerWithDynamicFlags already, so we could do whatever examining of the URIs we want, possibly informed by additional about module flags we add.

> but at least for the simple cases the vimium use case seems compelling and
> like something we ought to be able to handle

Yes, I agree, for the set of about: URIs that we want people navigating to manually.  Which is perhaps not all of them.

> But these are most important: addons, downloads, config, debugging, robots

I should note that about:downloads is an implementation detail of how we show downloads in private windows, and is not something that's guaranteed to keep existing, to work in non-private windows, etc...  Furthermore, it has actual UI to get to it in the case when it's supposed to work... (and yes, I know that's the UI vim-like things are trying to avoid).  Of course I agree that about:config and about:debugging are basically the only entrypoints to those pieces of UI.  And I have no objection in principle to exposing things like about:downloads as long as people understand that it could disappear at any time, I guess.

One fundamental problem with all this, of course, is that we are trying to not give webextensions full system privileges, which means we have to guard against anything that could lead to them escalating to full system access...  That means that we can't necessarily allow them to do everything the normal Firefox UI can do, because in security terms we trust the Firefox UI but not webextensions.  :(

Anyway, I think getting to the point where we're fairly confident that we can allow "about:something" for arbitrary "something" without query params or anchors is doable.

	Kris Maglione [:kmag]
	Comment 30 • 7 years ago

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #29)
> I should note that about:downloads is an implementation detail of how we
> show downloads in private windows, and is not something that's guaranteed to
> keep existing, to work in non-private windows, etc...  Furthermore, it has
> actual UI to get to it in the case when it's supposed to work...

For that matter, about:addons is also an implementation detail, with UI and a keyboard shortcut to get to it. Initially, we even hid the location bar whenever it was open. Arguably, it's not likely to stop working any time soon, and a lot of people probably use the URL as the primary way that they open it...

But I still don't want add-ons to start relying on the URL as a way to open the add-on manager. Same for the downloads manager. We have logic to try to re-use existing about:addons tabs and about:downloads tabs if they exist, and it's entirely possible that we may move to some other, non-tab-content UI for it in the future. (For which reasons we have separate bugs for adding actual APIs for opening built-in UIs like these)

	Colin Caine
	Comment 31 • 7 years ago

I don't think add=ons should rely on the URL either, but users will want to type `about:addons` into their address bar and have whatever firefox would do happen.

If it's not a security risk and the other API is visible and recommended, what's the problem?

But the UX is fine with either one of the APIs: if I can't really tabs.create about:addons, I'll just alias attempts to do that to the other API call (ui.addonsPage()?).

> That means that we can't necessarily allow them to do everything the normal Firefox UI can do, because in security terms we trust the Firefox UI but not webextensions.  :(

I understand that you're trying to maintain a sandbox around webextensions; I'm just trying to make sure it can fit a big V in it :)

	Adam Roach [:abr] Reporter
	Comment 32 • 7 years ago

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #28)
> > but I don't see a question directed at me here.
> 
> The question was what the link in comment 0 was supposed to be, because the
> link actually there has nothing to do with this bug.

Ah, yes. You found the right one. It appears that a message must have been removed from the archive, resulting in a message renumbering. That seems like rather unfortunate behavior -- I thought pipermail links were intended to be stable.

The message I was referring to is now at https://mail.mozilla.org/pipermail/dev-addons/2016-May/000609.html -- given that it has moved once already, I have no idea how long that will be true.

	Kris Maglione [:kmag]
	Comment 33 • 7 years ago

(In reply to Adam Roach [:abr] from comment #32)
> The message I was referring to is now at
> https://mail.mozilla.org/pipermail/dev-addons/2016-May/000609.html -- given
> that it has moved once already, I have no idea how long that will be true.

Permalink: http://web.archive.org/web/20171028045057/https://mail.mozilla.org/pipermail/dev-addons/2016-May/000609.html

	Sören Hentzschel
	Comment 35 • 7 years ago

> But these are most important: addons, downloads, config, debugging, robots

Not to forget about:newtab. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1371793#c8 for the use case.

	Kris Maglione [:kmag]
	Comment 36 • 7 years ago

about:newtab is one that we definitely should *not* allow. Tabs open with the appropriate new tab page automatically. about:newtab is an implementation detail, and should never be used directly.

	mrmr1993
	Comment 37 • 7 years ago

Again, from the Vimium side, we have users typing about:newtab to reach their top pages (when they've configured our open new tab command to open a different page). Implementation detail or not, it sucks when users ask us to open a page and we can't.

	Sören Hentzschel
	Comment 38 • 7 years ago

There *needs* to be a way to open the default new tab page or how the use case should be handled? It doesn't matter if I have to call it "about:newtab" in my add-on or if there will be a method to get the default new tab page, the point is that a way is needed to open the new tab page. I see no reasons in comment 36 why it should not be possible to open this page. So please don't say "we definitely should *not* allow" if there are no good reasons to forbid this…

It's by the way very annoying. In bug 1371793 it was said by Andy "Seems reasonable to me", then it was said in bug 1411647 this bug should be the way forward "so hopefully we'll come up with something that will help" and now we have the same discussion again…

	Boris Zbarsky [:bzbarsky]
	Comment 40 • 7 years ago

> but users will want to type `about:addons` into their address bar and have whatever firefox would
> do happen.

Right.  I strongly suspect allowing that particular string is not a problem.

> If it's not a security risk and the other API is visible and recommended,
> what's the problem?

There isn't one, _if_ we can prove "it" (whatever "it" is) is not a security risk.

I do think that any about: URI we suggest users type themselves is not a security risk pretty much by definition, if we disallow query and ref bits.

For what it's worth, I think marking things as duplicate of this bug is a _really_ bad idea, because we haven't even decide what this bug is going to be "about" anyway.  All those duplicates should be dependencies, and once this bug is fixed we should reevaluate them all to see whether they are then fixed or whether they need more work.

	Andrew Swan [:aswan]
	Comment 41 • 7 years ago

So to be clear, the approach here would be to create a new flag in nsIAboutModule and then add code here to map that flag to nsIProtocolHandler::LOADABLE_BY_EXTENSIONS?
http://searchfox.org/mozilla-central/rev/1ebd2eff44617df3b82eea7d2f3ca1b60cc591a0/netwerk/protocol/about/nsAboutProtocolHandler.cpp#75
And I presume this would also be the place where we would enforce the "without querying strings or anchors" restriction.

Then we create separate dependent bugs for each individual about: page we want to make available and we do the individual audits and bikeshedding about whether to expose them at all in those bugs?

	Boris Zbarsky [:bzbarsky]
	Comment 42 • 7 years ago

That seems like a viable path forward, yes.

	Patrick Marchwiak
	Comment 44 • 7 years ago

Some quick context: I'm trying to migrate my extension https://addons.mozilla.org/en-US/firefox/addon/auto-reader-view/ to the WebExtensions API and have run into this issue. This extension allows users to enable automatic switching to reader view for domains of their choosing. I've implemented this by essentially updating the URL to about:reader?url=CURRENT_URL when the user is on a stored domain. This no longer works as I get an "Illegal URL" error when calling browser.tabs.update.

Are there any plans to allow setting a "about:reader?url=stuff" using the WebExtensions API? I'm not sure I understand the security concerns...if access to these types of urls is exposed as an extra permission then a user would be aware of the extension's additional privileges at install time and would make a decision about whether to trust it or not. 

If access to "about:reader" is blocked then how about a reader API to enable reader view programmatically?

	Kestrel
	Comment 45 • 7 years ago

> reader API to enable reader view programmatically

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/toggleReaderMode

tabs.onUpdated also has changeInfo.isArticle (undocumented).

	Lazy Monkey
	Comment 46 • 7 years ago

I'd like a webextension to load about:downloads in a tab
thanks.

	Andy McKay
	Comment 47 • 7 years ago

Note that the ability to open a tab in reader mode was added in bug 1381992. I think at this point the best bet is to file bugs for each of the tabs (eg: tabs -> about:downloads) and windows (eg: tools -> downloads) we want to open as seperate bugs and block to this (I think some of those already exist). 

Then they can be evaluated on a case by case basis.

	Lazy Monkey
	Comment 48 • 7 years ago

Hi, as requested I have submitted bug 1420105 for about:downloads.

	Colin Caine
	Comment 50 • 7 years ago

I've opened a couple of dependent bugs, but I don't see why we can't just allow any about:* URL so long as it doesn't have any anchor or query strings. What possible attacks are thought possible? DoS, maybe, but extensions can already do that.

We're not passing any user input to these pages, we're just opening them. And the use case described above for UI-replacement add-ons is solid for any about page: I don't want to have to use different open page mechanisms for different pages.

Boris says: "I do think that any about: URI we suggest users type themselves is not a security risk pretty much by definition, if we disallow query and ref bits."

Can we at least fast stream config, debugging, healthreport, profiles, support?

	Rob Wu [:robwu]
	Comment 51 • 7 years ago

(In reply to Colin Caine from comment #50)
> I've opened a couple of dependent bugs, but I don't see why we can't just
> allow any about:* URL so long as it doesn't have any anchor or query
> strings. What possible attacks are thought possible?

Most about:* pages are privileged. If there is a vulnerability in these pages and an extension can open such pages without limitations, then that can result in security bugs. One year ago, there was such a bug in Chrome: https://crbug.com/668653

In Chrome it used to be possible to crash the browser by opening a certain debugging URL. The solution was to blacklist debugging URLs...

Another issue that I see quite often is extensions that call tabs.create or tabs.update without sanitizing the input. If powerful URLs are allowed by default in the tabs.create/update APIs, then the impact of having installed such a badly coded extension is more severe.


So allowing "about:*" without permissions should be out of the question.
Allowing a subset of "about:*" should be OK, especially if there are extra permissions for the more powerful URLs (including query string/reference fragment).

	Colin Caine
	Comment 52 • 7 years ago

> One year ago, there was such a bug in Chrome: https://crbug.com/668653

That bug requires the passing of a variable. I am specifically asking about being able to open the page without passing query or anchor parts, so that doesn't apply here.

If the page cannot receive input from extensions it's going to be tricky to do a XSS attack.

> In Chrome it used to be possible to crash the browser by opening a certain debugging URL.

Does the WebExtension API seek to prevent DoS attacks (here meaning Denial of the service of using firefox)? Because I'm pretty sure I can ruin a user's experience of firefox from extension code pretty easily and that this is not possible to fix at an API level.

> call tabs.create or tabs.update without sanitizing the input

I am specifically requesting that only URLs without query or anchor parts be permitted. There is no sanitization issue if that is done.

	Rob Wu [:robwu]
	Comment 53 • 7 years ago

(In reply to Colin Caine from comment #52)
> > One year ago, there was such a bug in Chrome: https://crbug.com/668653
> 
> That bug requires the passing of a variable. I am specifically asking about
> being able to open the page without passing query or anchor parts, so that
> doesn't apply here.

The bug does not require any variable. Merely opening "chrome://downloads" was sufficient (you can watch the attached video if you don't want to read the full report).

(I consider "about:downloads" to be a reasonable URL to whitelist given its legitimate use cases though.)

	Andrew Swan [:aswan]
	Comment 54 • 7 years ago

(In reply to Colin Caine from comment #50)
> Can we at least fast stream config, debugging, healthreport, profiles,
> support?

The work from comment 41 still needs to be done first.  I don't really care if that happens in this bug or a new bug gets opened for it but I don't think anybody from the mozilla side has time to work in this during the 59 cycle.  I'd be happy to help get patches from a volunteer contributor reviewed and landed though.