Clarifying the CSP restrictions with regard to `connect-src` and `unsafe-eval`.

chrome/common/extensions/docs/server2/templates/articles/contentSecurityPolicy.html

 <h1>Content Security Policy (CSP)</h1>
 
 
 <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 21 matching lines @@
 <pre>{
   ...,
   "content_security_policy": "[POLICY STRING GOES HERE]"
   ...
 }</pre>
 
 <p class="note">
   For full details regarding CSP's syntax, please take a look at
   <a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#syntax">
     the Content Security Policy specification
-  </a>.
+  </a>, and the <a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/">
+    "An Introduction to Content Security Policy"
+  </a> article on HTML5Rocks.
 </p>
 
 <h2>Default Policy Restrictions</h2>
 
 <p>
   Packages that do not define a <a href="manifestVersion.html">
     <code>manifest_version</code>
   </a> have no default content security policy. Those that select
   <code>manifest_version</code></a> 2, have a default content security policy
   of:
@@ skipping 159 matching lines @@
   &lt;body&gt;
     &lt;button&gt;Click for awesomeness!&lt;/button&gt;
   &lt;/body&gt;
 &lt;/html&gt;</pre>
 
 <h2>Relaxing the default policy</h2>
 
 <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.
+  <code>unsafe-inline</code> will have no effect. Likewise, there is no
+  mechanism for enabling <code>eval</code>-like constructs. Setting a script
+  policy that includes <code>unsafe-eval</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
   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, 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>
   To ease development, we're also allowing the whitelisting of resources loaded
   over HTTP from servers on your local machine. You may whitelist script and
   object sources on any port of either <code>http://127.0.0.1</code> or
   <code>http://localhost</code>.
 </p>
 
+<p class="note">
+  The restriction against resources loaded over HTTP applies only to those
+  resources which are directly executed. You're still free, for example, to
+  make XMLHTTPRequest connections to any origin you like; the default policy
+  doesn't restrict <code>connect-src</code> or any of the other CSP directives
+  in any way.
+</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'",
   ...
 }</pre>
@@ skipping 16 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>