1422049 - Isolate Containers to different Content Processes

Status: RESOLVED DUPLICATE of bug 1451850

(Core :: DOM: Core & HTML, enhancement, P5)

Description

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

By isolating containers to different content processes, we can create a type of site isolation. Site Isolation puts each origin in its own process _and_ enforces that requests coming in over IPC can only obtain data about that origin. This provides security: an attacker who compromises a content process for example.com can't ask for the cookies for gmail.com

Site Isolation gets tricky for several reasons: how do you handle when example.com makes an iframe for gmail.com; how do you handle navigation from example.com to gmail.com; and how do you handle the state space explosion of create a separate process for every origin a user visits?

However, containers side-steps a lot of these issues. Firstly, a user (probably) has a small number of containers, so the space explosion isn't a problem. Secondly, iframes and navigation aren't an issue. Navigating from example.com to gmail.com _will_ stay in the same container but if you never logged into gmail.com in that container there will be no data to steal (no cookies, no cache, etc). 

It also has a nice narrative: we're putting the _user_ in control of their security. They can choose what they want to isolate (by making a container and using it for their most-valuable-site). 

IPC-wise we would need to enforce userContextId (the container identifier, an int) restrictions in the parent process and only return data for the userContextId associated with the content process.

Process-wise I'm not sure what would need to be done, but one feature being investigated for containers is "Always open [example.com] in Container XXX".  That feature may make this harder, I'm not sure how that integrates or anything.

Comment 1

[Alex Gaynor [:Alex_Gaynor]]

Note to self: private browsing using the same mechanisms as containers, so this encompasses that as well.

Comment 2

[demiobenour]

How does the user choose which container to put a site in?

Also, I don’t think we can count on users to be this aware.  Site isolation should Just Work out of the box.  That is, every origin to which a user is logged in should have its own process.  The tricky part will be detecting logins.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

>How does the user choose which container to put a site in?

It's the one where the site was opened from:
https://blog.mozilla.org/tanvi/2017/10/03/update-firefox-containers/

>Site isolation should Just Work out of the box.  That is, every origin to 
>which a user is logged in should have its own process.

That's bug 1423406 I believe?

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

If we move towards a world where origins are isolated by process, then this just falls out naturally.  Containers are part of the principal which represents the origin in gecko.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

per comment 4 there shouldn't be anything special to implement here - unless we want this behavior sooner than bug 1451850.

Comment 6

[Neha Kochar [:neha]]

As Olli said in comment 5, this will be done with Fission.