Lock down the registration of blob:chrome-extension:// URLs

extensions/shell/browser/shell_browser_main_parts.cc

Index: extensions/shell/browser/shell_browser_main_parts.cc
diff --git a/extensions/shell/browser/shell_browser_main_parts.cc b/extensions/shell/browser/shell_browser_main_parts.cc
index a1c702add4cc90943d43ee35595c857a6b427da6..5b47a2f05c37ab5ab3ca1f3ab8af83e8710aa4e3 100644
--- a/extensions/shell/browser/shell_browser_main_parts.cc
+++ b/extensions/shell/browser/shell_browser_main_parts.cc
@@ -128,10 +128,13 @@ void ShellBrowserMainParts::PreEarlyInitialization() {
 int ShellBrowserMainParts::PreCreateThreads() {
   // TODO(jamescook): Initialize chromeos::CrosSettings here?
 
-  content::ChildProcessSecurityPolicy::GetInstance()->RegisterWebSafeScheme(
-      kExtensionScheme);
-  content::ChildProcessSecurityPolicy::GetInstance()->RegisterWebSafeScheme(
-      kExtensionResourceScheme);
+  // chrome-extension:// URLs are safe to request anywhere, but may only
+  // commit (including in iframes) in extension processes.
+  content::ChildProcessSecurityPolicy::GetInstance()
+      ->RegisterWebSafeIsolatedScheme(extensions::kExtensionScheme);
+  // TODO(nick): Kill off kExtensionResourceScheme.
+  content::ChildProcessSecurityPolicy::GetInstance()
+      ->RegisterWebSafeIsolatedScheme(extensions::kExtensionResourceScheme);

[ncarter (slow), 2016/09/29 16:27:43]

reillyg's comment prompted me to rethink this. If --isolate-extensions is not
fully functional in extensions shell (and it's not, afaik), then this is not
probably correct. However, the tests pass -- probably indicates that we don't
have extensions_browsertests that exercise oopif cases.

So two options here:
 (1) leave this as-is, for the sake of being consistent with chrome/; treating
this as a step towards having --isolate-extensions work in the extensions shell.
 (2) Revert this part of the change, and leave these schemes as web-safe until
we push an implementation of --isolate-extensions down into the //extensions
layer.

This situation makes me think it's fairly urgent to arrive at a consistent
process policy for extensions shell and chrome.

Thoughts?

[Devlin, 2016/09/29 17:31:09]

My $0.02: If this moves us toward parity, I'd say keep it.  We'll need it later,
and it might help us avoid regressing.

[ncarter (slow), 2016/09/29 21:01:46]

I decided to revert this hunk, with the logic that when we do push
--isolate-extensions down into src/extensions, we probably will want to move
this code to a shared location anyway.

 
   // Return no error.
   return 0;