There are often Chrome features that want to use a renderer process for special cases, such that they can grant custom JavaScript APIs to a page in the process.  This has come up for Contextual Search (issue 523554) and DOM Distiller, for example.

This is a problem today, because Chrome may choose an existing renderer process for these features if the user is over the process limit.  That process may already contain untrusted pages from the user's existing tabs, and thus the process may already be exploited and under an attacker's control.  Because these features grant privileges for the new custom JS APIs to the process, the attacker may try to use the APIs to escape the sandbox.

In the cases we've seen so far, the APIs are not particularly dangerous and are unlikely to help escalate an attack.  However, the security team has little visibility into changes to these APIs over time, and we've had problems in the past where they are overly powerful (e.g.,  issue 509313 ).

We should provide a mechanism to make it easy for these features to avoid sharing a renderer process with untrusted tabs.  This is awkward in the current process model logic and requires lots of knowledge of specific features.  Instead, it's probably better to turn off process reuse by default, and only turn it on in cases that we know and understand (e.g., among actual tabs, and separately among extensions).