1371793 - Allow the creation of tabs with about: URLs

Status: RESOLVED DUPLICATE of bug 1269456

(WebExtensions :: Untriaged, enhancement, P3)

Description

[Andy McKay]

Currently you can update, close, move and interact with about: pages using the tab API. The only about: page you can create is the newtab, if tab.create({}) is called, it defaults to calling the new tab.

I'd like to see if we can allow these. Some concerns I've heard so far are: 

* This makes it hard to change in the future if things change. I'm not concerned about this, Firefox has had about: pages for a long time and they change rarely. This should not block any serious Firefox development. And since they exist and appear in APIs already, that problem already exists.

* The page URL can contain URLs or fragments and we aren't sure how well sanitised those are. Is it possible to do something like about:reader?url="javascript(...)". Don't know. For that reason I'm pinging security for some help.

* It makes social engineering a little easier if an add-on can open about:config, or about:addons and try to encourage users to do things they really shouldn't.

Its possible that a small number of pages could be added to an approval list, rather than everything. For example about:reader or about:addons are popular.

If there's problems with some of these concerns, we could add in specific APIs for the most common pages. For example: tab.createReaderPage. You can already do something like this with runtime.openOptionsPage which open about:addons to your add-on.

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

Comment 1

[Shane Caraveo (:mixedpuppy)]

> If there's problems with some of these concerns, we could add in specific
> APIs for the most common pages. For example: tab.createReaderPage. You can
> already do something like this with runtime.openOptionsPage which open
> about:addons to your add-on.

We can special case some handling for those in tabs.create if necessary.

Comment 2

[Jim Porter (:squib)]

I've found that you can actually link to any about: page that has nsIAboutModule::MAKE_LINKABLE set, which makes this a little better than comment 0 implies. However, it's still annoying when you can't link to some about: pages... maybe adding a WebExtension permission to allow this across the board would help?

Comment 3

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Andy McKay [:andym] from comment #0)
> Currently you can update, close, move and interact with about: pages using
> the tab API. The only about: page you can create is the newtab, if
> tab.create({}) is called, it defaults to calling the new tab.

Your language here is a little vague - what do you mean by "update" in this context. I thought web extensions had very limited interaction with any tab which isn't web content privileged.  From MDN:
"...to use tabs.executeScript() or tabs.insertCSS() you must have the host permission for the tab"

And you can't get the host permission for about: pages (which is good). But I'm not sure about other ones. For example, tabs.captureVisibleTab() could be used to capture sensitive information from about:pages. 

> 
> * The page URL can contain URLs or fragments and we aren't sure how well
> sanitised those are. Is it possible to do something like
> about:reader?url="javascript(...)". Don't know. For that reason I'm pinging
> security for some help.

I don't know of any cases that are directly exploitable like this, but there might be. There are certainly a lot of dangerous pages like this, e.g. about:config?filter=sandbox.content.level

If we do allow an API I dont see any reason not to filter based on a whitelist which prohibits use of query string.

> * It makes social engineering a little easier if an add-on can open
> about:config, or about:addons and try to encourage users to do things they
> really shouldn't.
Im not super worried about that - if social engineering is your goal, convincing the user to install an extension which and THEN doing your bidding adds an additional step. Its easier just to tell the user to hit command+r and then paste a command.

> 
> Its possible that a small number of pages could be added to an approval
> list, rather than everything. For example about:reader or about:addons are
> popular.

If we DO want to do this, then I would strongly advocate for this whitelist approach. I would also advocate that we limit the use case (ie dont allow stuff like <a href=about:preferences>, only allow it for something like tabs.create(). The risks presented by allow the user to simply open a subset of about pages, would seem to be much less than allowing for more complex interaction.

Do we have a list of the common use cases? What types of about:pages are people trying to open and for what purpose?

Comment 4

[Andy McKay]

(In reply to Paul Theriault [:pauljt] from comment #3)
> (In reply to Andy McKay [:andym] from comment #0)
> > Currently you can update, close, move and interact with about: pages using
> > the tab API. The only about: page you can create is the newtab, if
> > tab.create({}) is called, it defaults to calling the new tab.
> 
> Your language here is a little vague - what do you mean by "update" in this
> context. I thought web extensions had very limited interaction with any tab
> which isn't web content privileged.  From MDN:
> "...to use tabs.executeScript() or tabs.insertCSS() you must have the host
> permission for the tab"

Sorry. You are correct, you can't change the actual contents because tabs.executeScript won't allow you. But because the page is just a tab, you can call most other tab APIs. For example: calling tabs.remove on the tab, or calling the tabs.update API on it.

> > Its possible that a small number of pages could be added to an approval
> > list, rather than everything. For example about:reader or about:addons are
> > popular.
> 
> If we DO want to do this, then I would strongly advocate for this whitelist
> approach. I would also advocate that we limit the use case (ie dont allow
> stuff like <a href=about:preferences>, only allow it for something like
> tabs.create(). The risks presented by allow the user to simply open a subset
> of about pages, would seem to be much less than allowing for more complex
> interaction.
> 
> Do we have a list of the common use cases? What types of about:pages are
> people trying to open and for what purpose?

Sounds good to me. There's a pretty limited subset, about:reader is the most common one (and linked to from this bug), about:addons, about:downloads... and that's really about it. We could probably just evaluate each one as the request comes up.

Comment 5

[Sören Hentzschel]

(In reply to Paul Theriault [:pauljt] from comment #3)
> Do we have a list of the common use cases? What types of about:pages are
> people trying to open and for what purpose?

(In reply to Andy McKay [:andym] from comment #4)
There's a pretty limited subset, about:reader is the most
> common one (and linked to from this bug), about:addons, about:downloads...
> and that's really about it. We could probably just evaluate each one as the
> request comes up.

I need to open about:sync-tabs in New Tab Override because some people want to use this as new tab page. It was implemented in New Tab Override as pre defined option because there was more than one request to do that. I don't have stats how many people use this option but it's a use case to see the synced tabs as new tab page.

Comment 6

[Andy McKay]

Please note that about:sync tabs was removed in Firefox 55 as per bug 1365273.

Comment 7

[Sören Hentzschel]

Oh, I didn't know that. Thank you for the information. So you can ignore comment 5. ;)

Comment 8

[Sören Hentzschel]

Could we please also add about:newtab to the list of allowed about: pages to open the default new tab page (aka Activity Stream in Firefox 57)?

Use case for my add-on New Tab Override: Users have different options for the new tab page and one option is to use the default new tab page without disabling or uninstalling the add-on.

It's very bad for user retention if users have to uninstall or disable the add-on to try and compare the different options. Also I don't want to explain to the users as part of the add-on that and how they have to uninstall or disable the add-on to enable the default new tab page, that's too much information for the user interface.

At the moment I don't see a way with WebExtensions to use the default new tab page without uninstalling or disabling the add-on which is overriding the new tab page. Or do I overlook something?

Comment 9

[Andy McKay]

Seems reasonable to me, but leaving for the design-decision-needed meeting.

Comment 10

[YF (Yang)]

A dupe of Bug 1269456?

Comment 11

[Colin Caine]

Was this bug ever triaged (or maybe design-decision-needed is a separate meeting?)?

This bug is relevant to my project[1] and I am willing to work on it (and it's probably easier to ship than the keyboard API :)

[1]: https://github.com/cmcaine/tridactyl/pull/8#issuecomment-333365259

Comment 12

[Colin Caine]

Blocks 1403295

We'd like to support this as part of the support work for the keyboard API/alternative UIs. In particular we want to support opening about:addons and about:downloads, but the more the merrier.

needinfo'ing aswan for support.

Comment 14

[David E. Ross]

This bug is about opening a new tab for the "about" functions, not necessarily relative to extensions.  Bug #1269456 is specifically about extensions.  Thus, this is not a duplicate of bug #1269456.

Comment 15

[Jim Porter (:squib)]

> This bug is about opening a new tab for the "about" functions, not necessarily relative to extensions.

Where are you seeing that? Comment 0 and every subsequent comment from what I can see are specific to WebExtensions.