1352431 - Provide a way for extensions to control domain -> content process mapping

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement, P3)

Description

[Jim Mathies [:jimm]]

We should allow this to be configurable for top level domains the browser  navigates to. I would think a service like Tor would find this useful, for example isolating tor from non-tor network addresses.

It might be nice to have control over certain sandbox settings as well.

Comment 1

[Andy McKay]

Could you expand on this at all Jim. Do you know what an API might look like? Are there any performance or security concerns from doing such an API?

Comment 2

[Jim Mathies [:jimm]]

ni'ing gabor for feedback. We chatted about this a while back - giving extensions control over content process management. I don't remember the specifics.

Comment 3

[Gabor Krizsanits (INACTIVE)]

(In reply to Andy McKay [:andym] from comment #1)
> Could you expand on this at all Jim. Do you know what an API might look
> like?

The API is to be decided, the interface we're exposing currently to JS for the process selection is: [1] and the default implementation is: [2]

This will be the underlying machinery we want to build a public API on. In a nutshell we can provide:
- the type of the process that is required for the action (web extension, web content, etc.)
- the number of processes that currently exists from that type
- the currently allowed maximum for that type
- and a list of nsIContentProcessInfo struct for the existing process for that type (this can be extended it's fairly trivial right now)

The algorithm then can choose one of the existing process to be used, or let the system create a new process for that type. For example every time a new tab is created that needs a content process, this will be called and it decides if we need a new process, or if not, which process to pick. Same for the web extension process(es).

[1]: http://searchfox.org/mozilla-central/rev/bbc1c59e460a27b20929b56489e2e55438de81fa/dom/interfaces/base/nsIContentProcess.idl#43
[2]: http://searchfox.org/mozilla-central/rev/bbc1c59e460a27b20929b56489e2e55438de81fa/dom/base/ProcessSelector.js#44

> Are there any performance or security concerns from doing such an API?

Performance: yes. Security: theoretically a very little, but nothing scary.
The reason we put limit on the number of content processes is because unlimited content processes would use a lot of memory + there are still a few area where we don't scale all that well. We might want to make sure that the API respects the limits.
Other than that if the API choose to always select the first process from the available N processes that would be like disabling e10s-multi... So there is space for screwing things up with the given API but we can limit the damage by exposing an API that is wrapped in another function internally that does some trivial checks to mitigate these issues (we could for example check if the add-on respects the max number of processes and if not throw a warning and fall back to the default process selector, but we probably also want to let add-ons to change that number within a sane limit).

Security: making sure that some URLs will always get in the same process as some other URLs (gmail.com, facebook.com) will disable the very moderated content separation what we have right now: there is a chance right now that they will be in different processes.

Comment 4

[Caitlin Neiman [:caitmuenster]]

Hi Jim, this has been added to the agenda for the December 5, 2017 WebExtensions APIs triage. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1vH4wqJJZt1jk-cpx5NOq67b1UNekeQog6bz2HFOHe5E/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 5

[Andy McKay]

I don't think this API meets a few criteria:

* It's not a high level API, it get's pretty into the weeds of how the browser works. Something that we've been trying to do in WebExtensions. For example, explaining to a user in permissions what add-ons that use this API actually do to the browser... would be hard.

* I'm not convinced we've got a valid use case yet, "Tor would find this useful", but they can do this without needing a WebExtension API since they can land patches in the tree anyway.

* There's very little chance of another browser adopting this.

The value doesn't seem to be worth the cost at this point. However Jim, if there's a better reason I'm missing, please let me know.