This falls under the category of “First, do no harm”:Ĭonsult the Platform and IPC teams (#ipc) to develop the plan for the way your process will integrate with the systems in which it will exist, as well as how it will be handled on any platforms where it will not exist. Informed by this history, there is some of non-obvious preparation that you should do before starting down this path. The same logic inspired the NPAPI (Flash) plugin process.
One of the benefits of the GPU process was that it improved browser stability by separating a system component that had frequent stability issues – GPU drivers. For example, we heavily sandbox content processes to protect from external code, while the File process, which is a content process that can access file:// URLs, has a sandbox that is similar but allows access to local files. Sandboxing processes offers great security guarantees but requires making tradeoffs between power and protection. The separation of memory spaces undermines many types of exploits. Site isolation requires additional processes to separate HTML and JS for different sites. Separating HTML and JS from the browser makes it possible to secure the browser and the rest of the system from them, even when those APIs are compromised.īrowser stability was also improved by separating HTML and JS from the browser, since catastrophic failures related to a tab could be limited to the tab instead of crashing the browser.
Here is an incomplete list of good reasons we’ve created new processes: Then, implementations on some platforms developed processes for graphics (“GPU” processes). Then, it split again so that the browser could also disentangle itself from web content (content processes). Then, one became two as NPAPI plugins like Flash were pushed into their own process (plugin processes) for security and stability reasons.
0 kommentar(er)
