Adding `chrome-extension` resources to the CSP relaxation documentation.

chrome/common/extensions/docs/static/contentSecurityPolicy.html

 <div id="pageData-name" class="pageData">Content Security Policy (CSP)</div>
 <div id="pageData-showTOC" class="pageData">true</div>
 
 <p>
   In order to mitigate a large class of potental cross-site scripting issues,
   Chrome's extension system has incorporated the general concept of
   <a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html">
     <strong>Content Security Policy (CSP)</strong>
   </a>. This introduces some fairly strict policies that will make extensions
   more secure by default, and provides you with the ability to create and
@@ skipping 207 matching lines @@
 
 <p>
   There is no mechanism for relaxing the restriction against executing inline
   JavaScript. In particular, setting a script policy that includes
   <code>unsafe-inline</code> will have no effect. This is intentional.
 </p>
 
 <p>
   If, on the other hand, you have a need for some external JavaScript or object
   resources, you can relax the policy to a limited extent by whitelisting
-  specific HTTPS origins from which scripts should be accepted. Whitelisting
-  insecure HTTP resources will have no effect. This is intentional, because
-  we want to ensure that executable resources loaded with an extension's
-  elevated permissions is exactly the resource you expect, and hasn't been
-  replaced by an active network attacker. As <a
+  secure origins from which scripts should be accepted. We want to ensure that
+  executable resources loaded with an extension's elevated permissions are
+  exactly the resources you expect, and haven't been replaced by an active
+  network attacker. As <a
   href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle
-  attacks</a> are both trivial and undetectable over HTTP, only HTTPS origins
-  will be accepted.
+  attacks</a> are both trivial and undetectable over HTTP, those origins will
+  not be accepted. Currently, we allow whitelisting origins with the following
+  schemes: <code>HTTPS</code>, <code>chrome-extension</code>, and
+  <code>chrome-extension-resource</code>.
 </p>
 
 <p>
   A relaxed policy definition which allows script resources to be loaded from
   <code>example.com</code> over HTTPS might look like:
 </p>
 
 <pre>{
   ...,
   "content_security_policy": "script-src 'self' https://example.com; object-src 'self'",
@@ skipping 18 matching lines @@
 
 <p>
   You may, of course, tighten this policy to whatever extent your extension
   allows in order to increase security at the expense of convenience. To specify
   that your extension can only load resources of <em>any</em> type (images, etc)
   from its own package, for example, a policy of <code>default-src 'self'</code>
   would be appropriate. The <a href="samples.html#mappy">Mappy</a> sample
   extension is a good example of an extension that's been locked down above and
   beyond the defaults.
 </p>