Share schemes needed for CSP between the browser and the renderer.

extensions/renderer/dispatcher.cc

Index: extensions/renderer/dispatcher.cc
diff --git a/extensions/renderer/dispatcher.cc b/extensions/renderer/dispatcher.cc
index 90aad5c3fe92cfada1a1dee4ca591aace1651a55..71574fff8ed8b1ca37977fa5ef033e2887fd1c47 100644
--- a/extensions/renderer/dispatcher.cc
+++ b/extensions/renderer/dispatcher.cc
@@ -269,11 +269,6 @@ Dispatcher::Dispatcher(DispatcherDelegate* delegate)
   // Register WebSecurityPolicy whitelists for the chrome-extension:// scheme.
   WebString extension_scheme(WebString::fromASCII(kExtensionScheme));
 
-  // Resources should bypass Content Security Policy checks when included in
-  // protected resources. TODO(kalman): What are "protected resources"?
-  WebSecurityPolicy::registerURLSchemeAsBypassingContentSecurityPolicy(
-      extension_scheme);

[Mike West, 2017/02/08 14:59:53]

We register `extension_scheme` as bypassing CSP, supporting Fetch, and being
"first-party" when top-level. I wonder if it would be better to wrap these
concepts up into one ball of schemes that are non-webby, but somehow privileged.
I don't have a good name for that concept.

[nasko, 2017/02/09 00:13:15]

In what sense are they non-webby? To me non-webby means mailto: or external
protocols. Extensions are very much webby, but not web : ), also privileged.

-
   // Extension resources are HTTP-like and safe to expose to the fetch API. The
   // rules for the fetch API are consistent with XHR.
   WebSecurityPolicy::registerURLSchemeAsSupportingFetchAPI(extension_scheme);