1491018 - (fission-ipc-map) Create Authoritative 'This Origin to this Content Process' Infrastructure

Status: NEW

(Core :: DOM: Content Processes, enhancement, P3)

Description

[Tom Ritter [:tjr]]

For the fission-ipc bugs to be solved, we need to create an authoritative mapping of Content Processes -> Origin.  This maps needs to be used in the Parent Process, but also propagated to all Utility Processes: Necko, RDD, Web Extensions, etc so they can use it too.  (The GMP process is one-per-origin already so it shouldn't need this.)

This way the non-Content Process (Parent, Necko, whatever) can validate that the Content Process they are talking to is permitted to impart actions upon the Principal/OriginAttributes/whatever they supplied over IPC.

Initially, I thought we could also refactor the Actors so that an Actor instance only interacts with at most one Content Process. This means that the Content Process it interacts with is known, and there would be no need to supply a Principal or OriginAttributes in IPC methods. 

However that is not the case, since a single Content Process may host tabs for an origin example.com from multiple Containers, Private Browsing Modes, and First Party Isolation Contexts. So we still need to supply which of those the particular request is for, but validate that the overall origin is permissible.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

I'd suggest that involving the Clients API might be a good strategy.  (NB: I do see you've filed bugs against the Clients API like bug 1491113.)

:bkelly's original introduction on dev-platform at https://groups.google.com/d/msg/mozilla.dev.platform/MfWMpMAuYLI/aPjQo2V_BQAJ is a good contextualizer.  But in short:
- We should have a Client for every global, be it window or worker.
- Every Client has a unique id. (See IPCClientInfo::id https://searchfox.org/mozilla-central/rev/dd965445ec47fbf3cee566eff93b301666bda0e1/dom/clients/manager/ClientIPCTypes.ipdlh#29).
- The overloaded ClientManager::CreateSource (https://searchfox.org/mozilla-central/search?q=ClientManager%3A%3ACreateSource&path=) creates the clients.  It currently takes an origin and allows content processes to be authoritative.
  - This could be changed to take a pre-authorized "origin token"/pre-allocated id, or an existing client id for the same origin.  I assume the idea for fission is that whenever we realize we want to load a document for a different origin, we go to the parent process and ask it to load that origin somewhere.  The parent then decides what process to put it in.  At this point it could create an entry in the Clients mapping that can be "redeemed" in the content process, with the parent also asserting that it was redeemed in the right process then the ClientSource's actor is created.  In the case of a same-origin client, the API could take the existing ClientId and the parent process could validate that yes, origin A in content process 1 is allowed to mint another Client for origin A in the same content process.
- We can then use the client id's more directly in other APIs and provide helpers to enforce a match between content process and client id.

Comment 2

[Tom Ritter [:tjr]]

Unless this needs a lot of patches/bugs to land, I don't think this is meta. It just blocks a lot of work.

Comment 4

[Chris Peterson [:cpeterson]]

This bug is not a Fission MVP blocker.