With Site Isolation and the --isolate-origins=https://foo.com flag, it's possible to define a list of origins and sites that each require dedicated processes.  As the list of sites grows, it may lead to the creation of too many processes.

Chrome currently has a process limit, after which web sites are allowed to share processes with each other.  There's some ad hoc logic for extensions in ChromeContentBrowserClientExtensionsPart::IsSuitableHost which says all extensions are allowed to share with each other but not web sites.  (There's a similar bucket for hosted apps.)

If we can generalize this, it might be a useful way to protect a larger set of sites from the general web without as much impact on the process count.  For example, enterprises might define a list of corporate sites which might start sharing processes with each other when the user is over the process limit, but which should never share a process with external sites.  We could even allow some of this sharing proactively to help the user stay under the limit, such as the current code that limits extensions to at most 1/3 of the full process limit.

It would be good to provide this as an abstraction within content/ to remove some of the custom code in the extensions layer (e.g., the RenderProcessHostPrivilege enum), perhaps as a set of URL pattern sets.  The members of the set might be assumed to be isolated origins.

Some challenges include:
1) Reconciling LockToOrigin vs RequiresDedicatedProcess.  (Today, that's the difference between isolated origins and extensions, and whether we can enforce site-specific checks on a process.)
2) Making as specific enforcements as possible (e.g., only allowing access to data for the origins known to be in the process, not all origins in the group).
3) Handling extension corner cases, like hosted apps.  Most chrome-extension:// URLs could be assumed to be isolated origins that share a group with all chrome-extension://* URLs, but we somehow want to exclude hosted apps from that category.