Move existing kSitePerProcess checks to a policy-oracle object

content/browser/child_process_security_policy_impl.cc

Index: content/browser/child_process_security_policy_impl.cc
diff --git a/content/browser/child_process_security_policy_impl.cc b/content/browser/child_process_security_policy_impl.cc
index bb4a3e217a5a38a496ba7c7d7ea9da9f2ab4284a..c1da0e9ec4737a2442e9d9789256a19740b8ab20 100644
--- a/content/browser/child_process_security_policy_impl.cc
+++ b/content/browser/child_process_security_policy_impl.cc
@@ -16,7 +16,7 @@
 #include "content/public/browser/content_browser_client.h"
 #include "content/public/browser/render_process_host.h"
 #include "content/public/common/bindings_policy.h"
-#include "content/public/common/content_switches.h"
+#include "content/public/common/site_isolation_policy.h"
 #include "content/public/common/url_constants.h"
 #include "net/base/filename_util.h"
 #include "net/url_request/url_request.h"
@@ -566,11 +566,11 @@ bool ChildProcessSecurityPolicyImpl::CanLoadPage(int child_id,
                                                  ResourceType resource_type) {
   // If --site-per-process flag is passed, we should enforce
   // stronger security restrictions on page navigation.
-  if (base::CommandLine::ForCurrentProcess()->HasSwitch(
-          switches::kSitePerProcess) &&
+  if (SiteIsolationPolicy::DoesSiteRequireDedicatedProcess(url) &&
       IsResourceTypeFrame(resource_type)) {
     // TODO(nasko): Do the proper check for site-per-process, once
     // out-of-process iframes is ready to go.
+    // TODO(nick): Can we trust |resource_type| here?
     return true;

[Charlie Reis, 2015/07/13 22:13:14]

This whole function is in kind of a weird state.  Robert introduced it way back
in https://codereview.chromium.org/11416121/, and Nasko disabled it when
starting the OOPIF prototype in https://codereview.chromium.org/11772005.

It seems to me that we don't need it anymore.  It was meant as a way to block
cross-site iframes before we had OOPIFs (https://crbug.com/159215).  With
document blocking (https://crbug.com/268640) and killing renderers that commit
bad URLs (https://crbug.com/85128), we don't need to also block the request in
the ResourceLoader in this way.

I'd propose ripping it out entirely, either before or after this CL lands.

[ncarter (slow), 2015/07/20 17:45:46]

I've got another CL to rip this out completely.

   }
   return true;