Confirmed users
346
edits
Nested Content Processes: Difference between revisions
Jump to navigation
Jump to search
→Implementation
No edit summary |
|||
| Line 17: | Line 17: | ||
== Implementation == | == Implementation == | ||
=== Process Creation === | |||
[[File:Nested-process.png|650px | [[File:Nested-process.png|650px|Nested Process]] | ||
PBrowser are now managed by either PContent or PContentBridge so TabParents could be created in content process now. | |||
Here is the steps for setting up nested OOP frame: | |||
# Child process A ask chrome process to create a grand child process via PContent::CreateChildProcess() | |||
# Child process A ask chrome process to bridge to grand child process B via PContent::BridgeToChildProcess() | |||
# Child process A creates new PBrowser over PContentBridge::PBrowser | |||
=== Security === | |||
[Needs security review] | |||
The sandbox model is built on the process boundary. Generally the chrome process shouldn't trust the information coming from a content processes. The content processes also shouldn't trust the information coming from other content processes. | |||
How do we check the integrity? For the messages from child to chrome we could | |||
# Check if the process is the app as it claimed to be by comparing ContentParent::OwnOrContainingAppId() {{bug|1020157}} | |||
# Check if the is indeed created and managed by the PContentBridge. When the content process creates a new TabParent/TabChild pair between it and the grand content process, it should send a notification to the chrome process. The chrome process will note that and check if the PBrowserId is indeed owned by the content process {{bug|1020172}} | |||
=== Testing === | |||
TBD | |||