Electrolysis security

Cross-posting to dev-tech-dom & dev-security.

As part of Electrolysis development, we need to consider the security  
implications of the architecture we are implementing.  Even though  
security per se is not an explicit goal at this point (phase 2) of the  
project, the risk remains that we could actually introduce a number of  
security issues while refactoring the code into separate processes.   
Some areas of risk that come to mind:

1) separating atomic security checks across IPC boundaries could  
introduce security bugs from security checks failing due to
  a) race conditions (ex. redirect could happen while a related  
security check happens on the other side of the IPC boundary)
  b) context sync issues (ex. redirects notifications may not be  
propagated across IPC)
  c) plugins/NPAPI may have odd behavior when in a separate process  
from chrome

2) security foundation for process isolation / low rights
  a) routing all network access through parent process
  b) how/when can remote tabs access cookies, password manager,  
certificate information, file system access for file upload/download
  c) avoiding proxies for the above - don't have a generic process in  
the parent process that just passes through all requests from remote  
processes
  d) preventing impersonation of chrome dialogs by a remote process  
(to the degree feasible)
  e) cache - who determines origin of documents, who writes to cache?

A larger threat model is located at https://wiki.mozilla.org/Security/ProcessIsolation/ThreatModel 
.  Though it is focused on security improvements from process  
isolation, it should still provide useful information for laying the  
foundation for future phases.

The goal is to start a discussion around the security implications of  
electrolysis so please chime in, even if its with general  
skepticism. :)  Thanks,
   Lucas.